John Peacock wrote:
> Vincent Starre wrote:
>
>> Basically: when doing the /diff/, use the old svn:keywords, then only
>> use the new svn:keywords for the actual application of keywords.
>
>
> I'd have to look at the code, but there is the distinct possibility
> that the old svn:keywords isn't available at the point of merging. In
> any case, this isn't cause of the conflict, per se. If you continue
> to leave Id in svn:keywords, you'll see that you still get a conflict
> (in the first example from your script).
>
> AIUI, what happens is that the WC file is compared against the
> textbase copy, which is not expanded. If there is keyword expansion
> involved, the WC file is unexpanded and only then compared against the
> textbase. If the only difference is between expanded and unexpanded
> that isn't a conflict. But you changed the same line that Subversion
> is expecting to be unexpanded, so it _is_ a conflict. See below for
> the way to prevent this from happening (as I don't see any way to do
> it programmatically).
>
>> 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.
>>
>
> Apply this diff to your original example script (watch for line wrap):
>
> $ diff bugtest.orig bugtest
> --- bugtest.orig 2005-09-30 10:49:22.308719856 -0400
> +++ bugtest 2005-09-30 10:51:07.318544448 -0400
> @@ -10,6 +10,8 @@ svn propset svn:keywords 'Id' keywords/k
> svn ci keywords -m "keyword conflict test (commit 2)"
> svn update keywords
> echo -e 'AAA\nBBB\n$Revision$\n$Date$\nCCC\nDDD\nEEE\nFFF\nGGG' >
> keywords/keyed
> +svn ci keywords -m "keyword conflict test (commit 2b)"
> +svn update keywords
> svn propset svn:keywords 'Revision Date' keywords/keyed
> svn ci keywords -m "keyword conflict test (commit 3)"
> svn update keywords
>
> And you'll see that there are no conflicts anywhere. The problem was
> both changing the text on the already expanded line _and_ changing the
> svn:keywords at the same time. It _is_ a conflict then because the
> same line did change in two different ways (locally modified by
> keyword expansion _and_ locally modified by changing that line).
>
> John
>
But the point is the conflict does not occur on the side which modifies
that line!
Modified by one side, which changes the line
Modified by the other side only through keyword expansion- no user
intervention!
if there is no user intervention on that line, there should never be a
conflict on that line.
svn _already_knows_ it should not raise a conflict, otherwise there
would be a conflict even for "untouched" files (ie: files which have
changes only because of keyword expansion)
It is not locally modified by keyword expansion _and_ locally modified
by changing that line, it is locally modified by keyword expansion and
remotely modified by changing that line. It is locally modified by
keyword expansion and locally changing a different and far away line. I
assure you: nobody but the person who changed $Id$ to $Date$ changed
that line :)
Now, while your workaround is one method, I personally think anything
which requires me to make an intentionally broken commit is a bug ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 18:02:55 2005