John Peacock wrote:
> Vincent Starre wrote:
>
>> If I start with a file containing $Id$, with svn:keywords of Id, then
>> change that to $Revision$ with svn:keywords of Revision, the new
>> value of svn:keywords is used to un-expand the keywords in the file
>> before attempted merging.
>
>
> Hmmm, this is bug in the sense that it may cause confusion during
> merges, but it is correct in the sense that the basic design of
> keyword expansion specifically permits "freezing" an expanded keyword
> by removing that entry in svn:keywords. Once you remove the entry
> from svn:keywords, that keyword text is no longer considered special
> in any way; it is now just a string of text. I cannot think offhand
> why this would be /useful/, but there it is.
>
> I think the appropriate fix is to add documentation emphasizing that
> if you remove a keyword entry from svn:keywords, any existing expanded
> keywords in the source files will not be unexpanded and that this
> could cause problems with merging later.
>
> John
>
Yes, I do know /why/ the bug is there, that is: it's a simple oversight.
"Freezing" is certainly still something which can be done, if the person
who removes the svn:keywords entry also leaves the line as it is.
However, as far as the person running "svn update" is concerned, he /has
not done anything to those lines/, therefor it is not logically a conflict.
SVN already takes this into account: it doesnt apply the new
svn:keywords property until after it has already checked to see which
files need to be merged. It should go one step further, though: it
should not apply the new svn:keywords property until after merging has
taken place. I suspect (though haven't checked) the reason it currently
aplies before merging is so that it can update the keywords while doing
the merge. (so it doesnt need to go over each file twice). Basically:
when doing the /diff/, use the old svn:keywords, then only use the new
svn:keywords for the actual application of keywords.
Trust me, this _is_ a bug, and serves no one. Elimination of this bug
would in no way harm "freezing". And if you ever run into this bug, it's
quite annoying :)
My situation, just to provide a clear picture:
We added $Id$ tags to all files. This in itself was an annoying commit,
simply because it effected every file, everyone had to check what was
being merged. Not SVN's fault there, just the kind of tedium expected
whenever you make a change to all files (like updating a copyright
notice, etc- we await user-defined keywords for the glory of
$Copyright$, of course ;) )
And then we decided we wanted to go from $Id$ to $Revision$ $Date$,
simply because we dont like showing off our valid system account names
to everybody.
Of course, we removed Id from svn:keywords because, hey, we werent using it.
Then a week later, everyone wants to commit again. This is a huge
logical problem. Are we to leave "Id" indefinitely, just because we used
it once, in order to prevent "conflicts"? No, of course not, the
conflicts don't really exist, so we should report them as a bug ;)
Note: the working copy which still contained the $Id$ after the copy
with $Date$ was committed _NEVER_ touched the $Id$ line. svn itself
updated the $Id$ line.
Also note: Files which were not changed by the user were not effected,
they updated cleanly. This is evidence of the bugness of this bug. Even
if you want to (DO NOT DO THIS :) ) have this result in a conflict, it
should then /always/ result in a conflict. It is merely inconsistent and
buggy at the moment.
so there :D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 16:30:16 2005