merge, --reintegrate, --record-only, near infinite regress in --use-merge-history

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
Received on 2010-06-02 11:34:02 CEST