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

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