On 2009-08-05 10:53:41 -0400, John Peacock wrote:
> Vincent Lefevre wrote:
> > Hi Stephen,
> >> Creating a new file with that string in it, importing into a
> >> Subversion repository, and setting its svn:keywords property has
> >> the desired affect. The file in the working copy contains a
> >> Subversion-style value:
> >> $Id: alpha 2 2009-08-05 13:28:53Z steve $
> >> and its text-base contains the unexpanded keyword:
> >> $Id$
> > Has this *always* been like that? It doesn't seem so.
> Yes it has always been that way; the keywords are kept in the repo and
> text-base unexpanded and only expanded in the working copy. It has to
> be that way so that the working copy can be unexpanded prior to
> comparison with the text-base for diff purposes.
I think you mean that it *should* have always been that way.
But in practice, there were/are bugs.
> Since the contents of the svn:keywords can be dynamically generated,
> they must be ignored for diff (and repo-storage) purposes.
Yes, but if it happens that a repository or dump has some string S
that looks like an expanded svn:keyword and the keyword is removed
later (such repositories or dumps can occur in practice, as shown
here), then the original string S must be taken into account at
Subversion seems to behave correctly when the head is checked out,
but if I do incremental updates (that was from r2769 to r2770 in my
example), I get local modifications.
> It isn't necessary to involve CVS or RCS in order to trigger this
> misbehavior: merely checking in something that matches an expanded
> svn:keyword, then in a later commit enabling that keyword can cause
> problems. I thought that this misbehavior was fixed by the keywords
> rewrite a while ago, but maybe not...
Perhaps, but when I did the commits, it wasn't fixed yet.
Vincent Lefèvre <email@example.com> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Received on 2009-08-05 17:50:27 CEST