Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> Without thinking, I wrote:
>
> > And since we're talking about property policy: in another message you
> > mentioned the commit timestamp property. This is clearly a property
> > users have to see (it's not ra-layer specific), but I think users
> > shouldn't be able to modify it. I think we need a new class of
> > read-only properties. I think these will always be properties that are
> > generated by the server. Commit timestamp is one, committer ID is
> > another, also (I think) the repository revisioin number that a file
> > revision first appears in (we're generating that, aren't we?) .
>
> I think I goofed this one. These props are generated on the server
> during a commit, so there's no way a client can set them. Also, once
> committed, they're cast in stone -- we can't change history in the
> repository.
>
> So there's really no issue here. Correct?
Right now, the only auto-generated properties are *revision* props.
When a transaction is created, an "svn:datestamp" property is attached
to the transaction itself. When the transaction is committed, this
property's value is re-set as a revision property.
AFAIK, we have no way (or plans) to allow the client to modify
revision properties. The client can only set node props -- although I
suppose revision props will be implicitly visible via the "annotate"
and "log" subcommands.
Here are reserved "svn:" props that will probably be attached to
revisions:
* datestamp
* username of committer
* log message
I suppose we could allow 'svnadmin' to change revision props -- say,
if the log message needs tweaking after the fact.
-------------
A separate, but related, thread: remember that we also plan to
auto-generate certain regular node-props eventually, such as (?)
* svn:owner
* svn:posix-access-permissions
* svn:mime-type
...and so on. This needs to be discussed more, as it's on our TODO
list for M3.
In particular, I'm worried about UI issues. A long time ago, we
agreed that it would be good to "hide" node properties from CVS users
who are just migrating to Subversion. That's why the status command,
despite that it has the two letter codes side-by-side, always draws
the second code as " " instead of "_" if no properties are present.
Our thought was: "if the user starts using props, then she'll see
`__' status codes. Otherwise, she'll not be aware of them."
I don't care so much about this goal anymore... but I thought I'd
point out that if we start auto-generating these props, users will see
"__" from the beginning.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006