[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: serious bug: a succession of "svn up" can yield a working copy with local changes

From: John Peacock <john.peacock_at_havurah-software.org>
Date: Wed, 05 Aug 2009 10:53:41 -0400

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. Since the contents of
the svn:keywords can be dynamically generated, they must be ignored for
diff (and repo-storage) purposes.

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...


Received on 2009-08-05 16:53:57 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.