Bah!! (I'm a just a wee bit frustrated as I write this, please forgive any roughness in tone.)
After waiting patiently for $JOB to finally move our server to Subversion 1.6, I'm finding Subversion's merge tracking to be rather less help than I'd hoped. (I guess git/hg/bzr have spoiled me during my two year wait.) What's really, really, really biting me at this point is a modification of the --reintegrate workflow that I've seen described on this list a few times: usual way: - create topic branch from trunk - svn merge trunk topic regularly during development to keep topic branch up-to-date with trunk - svn merge --reintegrate topic trunk merges the topic back to trunk - svn rm topic get rid of the topic branch. recreate if necessary. as the next sync merge would cause it to try to pull in its own reintegration leading to much gnashing of teeth. A few clever people suggested a way around the delete-and-recreate the branch problem. Just use a record-only merge to make the topic branch aware of the reintegration revision on trunk without actually enduring the resulting conflicts. It sounded like a great idea when I read it. Very clever. Unfortunately, it's also *very* *broken*. This technique interacts badly with "svn log -g". After a few repetitions of merge, merge --record-only, merge --reintegrate, I'm finding the same revisions showing up over and over again in my trunk when using svn log -g. svn log -q | wc -l 2299 svn log -q -g | wc -l 14167 $ svn log -q -g | egrep -o -e "^r[0-9]+" | sort | uniq -c | sort -n | tail 131 r42278 135 r42171 135 r42251 135 r42252 136 r42196 136 r42205 136 r42219 136 r42223 191 r42282 <-- these two revisions appear 191 times in the log -g of trunk! 191 r42292 <-- When this has made svn log -g useless for me. ("Include merged revisions" in TortoiseSVN is similarly useless). This is unfortunate, because I had hoped that this feature would free me from having to painstakingly protocol which revisions were merged in the log message as I used to do in 1.4 days. What's worse is that log -g uses historical information from the repository (not just HEAD), so it's impossible to undo this error by just deleting svn:merge-info properties and starting over. It appears only dump, remove svn:merge-info properties, load of the whole repository could fix things. Is that my only way to correct this idiocy? Does the Subversion Book include a big red warning label that I overlooked? As a work-around, is there a way to limit the recursive depth of log -g? // Ben