Another keyword-related conflict bug in need of confirmation

[Vincent Starre <vs...@comcast.net>]

A conflict is detected when merging a "binary" file which uses keywords. 
This conflict is manufactured by SVN, and does not really exist:
http://nifityni.dyndns.org/t.sh

This may or may not be another encarnation of the same bug I found a 
while back (whose details elude my memory at the moment, but whose 
more-convoluted demonstration script I still seem to have here: 
http://nifityni.dyndns.org/makeconflict )

At the time, I didnt submit it to the tracker because I couldnt get 
anyone else to agree it was actually a bug. Hoping to have better luck 
this time.

The original (makeconflict) was an extreme edge-case, if I'm remembering 
correctly: I think it was only happening when changing one keyword into 
another. This new one (t.sh) has just hit me on some very old keywords, 
however. (The same ones I previously altered, actually ;))

It is my belief, though not knowing the code I can't say with certainty, 
that both of these are a result of the same problem of not un-expanding 
keywords before calculating merges/potentialConflicts

In the first case (again, memory is ellusive, so I'm not sure if I'm 
remembering correctly), keywords were being unexpanded, but only based 
on the /new/ property. In this new case ("binary"), keywords seem to 
simply not be un-expanded.

Note that the new case's conflict does NOT appear when doing an update, 
only when doing a merge.


On a maybe-unrelated note, darix was trying to convince me that "svn 
merge -rBASE:something ."(on a fresh copy) was capable of legitimately 
causing conflicts, but unfortunately he ran off before I could 
understand him. If anyone can clear this up for me, I'd love to 
understand that. I really don't see how "apply the diff between x and y 
to x" could possibly be conflicting (I mean, wouldnt that mean x was 
different from itself?) Makes me think I am lacking some more 
fundamental knowledge of what merge is actually doing.
Again, that's barely-related, so I'd much prefer a response to the first 
part of this message :)



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Another keyword-related conflict bug in need of confirmation

[Lieven Govaerts <lg...@mobsol.be>]

Vincent, 


your email is a bit confusing, so I'm not really surprised you didn't get an
answer yet. 

However, your 't.sh' script is a correct recipe of what looks like a bug, or
rather an unimplemented feature. 

To start, I created a slightly smaller version of your script:
-----
# Change this variable to your sandbox repository path:
REPOS="http://localhost/svn/"

set -x

mkdir t
svn import t "$REPOS"/t -m "Initial Import"
rm -rf t
svn co "$REPOS"/t t

cd t
# create a file with a keyword
echo -e "$Revision$\nBBB\nCCC\nDDD\nEEE\n" > file
svn add file
svn propset svn:keywords "Revision" file
svn propset svn:mime-type "application/octet-stream" file
svn ci -m "Added file, mime type = binary, set keyword Revision"

# make a change
sed -i 's/CCC/CHANGED/' file
svn ci -m "Change file"
svn up

# this revert will generate an unexpected conflict:
svn merge -rBASE:PREV .

svn rm "$REPOS"/t -m "Cleaning up"
----

In short: 
Step 1: create a binary file that contains a keyword and commit
Step 2: make a change on that file and commit
Step 3: revert that change
Step 4: conflict: the local file will still contain the expanded keyword.

I checked the code on subversion trunk. In merge.c ( rev. 18433 ) at line 74
it shows that for text files, the local file is unexpanded before starting
the merge. However, for binary files ( line 295 ) the source code contains
this comment:
      /* ### when making the binary-file backups, should we be honoring
         keywords and eol stuff?   */

So your assumption was correct.

There are in my opinion two options here:
1. Keyword expansion in binary files is disabled altogether. Why would you
use it anyway?
2. A patch is provided to implement keyword unexpansion for binary files as
well. I'm pretty sure this is only a small task as the code is already
available for text files. 

I checked the issue tracker and there's no issue for this behaviour yet, so
feel free to report it. 

Lieven.

> -----Original Message-----
> From: Vincent Starre [mailto:vstarre@comcast.net] 
> Sent: vrijdag 10 februari 2006 17:17
> To: Subversion List
> Subject: Another keyword-related conflict bug in need of confirmation
> 
> A conflict is detected when merging a "binary" file which 
> uses keywords. 
> This conflict is manufactured by SVN, and does not really exist:
> http://nifityni.dyndns.org/t.sh
> 
> This may or may not be another encarnation of the same bug I 
> found a while back (whose details elude my memory at the 
> moment, but whose more-convoluted demonstration script I 
> still seem to have here: 
> http://nifityni.dyndns.org/makeconflict )
> 
> At the time, I didnt submit it to the tracker because I 
> couldnt get anyone else to agree it was actually a bug. 
> Hoping to have better luck this time.
> 
> The original (makeconflict) was an extreme edge-case, if I'm 
> remembering
> correctly: I think it was only happening when changing one 
> keyword into another. This new one (t.sh) has just hit me on 
> some very old keywords, however. (The same ones I previously 
> altered, actually ;))
> 
> It is my belief, though not knowing the code I can't say with 
> certainty, that both of these are a result of the same 
> problem of not un-expanding keywords before calculating 
> merges/potentialConflicts
> 
> In the first case (again, memory is ellusive, so I'm not sure 
> if I'm remembering correctly), keywords were being 
> unexpanded, but only based on the /new/ property. In this new 
> case ("binary"), keywords seem to simply not be un-expanded.
> 
> Note that the new case's conflict does NOT appear when doing 
> an update, only when doing a merge.
...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org