[Julian Foad]
> > True. The only frustrating thing is that you can't use 'svn
> > revert' to get rid of the local mod.
>
> Did you mean, "you can't use 'svn revert' to contract the keyword" ?
Yeah, you can't use svn revert to get rid of the local diff because
that also gets rid of the keyword change.
It's easy enough to work around, using 'svn diff | patch -R', assuming
a sufficiently sophisticated user. So I'm not really worried about it.
> What happens if there is an expanded keyword in the repository (which
> can easily happen if it wasn't mentioned in the 'svn:keywords'
> property at first, but is mentioned later)? In this situation, if
> the 'svn:keywords' property was set by a hypothetical remote-propset
> command, what would then happen at the client, or what would we want
> to happen?
I would expect the server to continue to store every active $Keyword$
in the canonical collapsed form, as it does now. But I suppose the
logic for this is entirely client-side. A direct mode 'svn prop*'
family of commands would imply having to put such logic in the server,
which seems unfortunate. (I mean particularly for the case of _adding_
a keyword - the server would want to collapse instances of the keyword
in the affected file.)
> Finally, but importantly, why are we only talking about contracting
> keywords?
We're talking about any change to the svn:keywords property - both
adding and removing keywords. For the add case, libsvn_wc already does
the right thing and expands keywords in the WC (though at commit time,
not at propset/propedit time). Doing it at propset/propedit time is
probably not worthwhile, since (at least for $Id$) the string will
change at commit time anyway.
> Surely, if we expect 'svn' to contract a keyword when we remove its
> name from the property, we should also expect it to expand it when we
> insert its name in the property.
Doesn't that happen today? Or do you mean doing it immediately rather
than deferring it to the next commit?
Received on Thu Mar 16 00:24:12 2006