RE: Another keyword-related conflict bug in need of confirmation
From: Lieven Govaerts <lgo_at_mobsol.be>
Date: 2006-02-11 13:40:01 CET
your email is a bit confusing, so I'm not really surprised you didn't get an
However, your 't.sh' script is a correct recipe of what looks like a bug, or
To start, I created a slightly smaller version of your script:
# make a change
# this revert will generate an unexpected conflict:
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:firstname.lastname@example.org] > 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: email@example.com For additional commands, e-mail: firstname.lastname@example.orgReceived on Sat Feb 11 13:43:33 2006
This is an archived mail posted to the Subversion Users mailing list.