svnmerge.py handling of reflected merges

On Sun, 02 Dec 2007, Blair Zajac wrote:

> Daniel Rall wrote:
> >On Sat, 01 Dec 2007, Blair Zajac wrote:
> >
> >>Ben Collins-Sussman wrote:
> >>>On Nov 30, 2007 4:23 PM, Blair Zajac <blair@orcaware.com> wrote:
> >>>
> >>>>It just works. I mean, you still can get conflicts when you merge back
> >>>>and you
> >>>>resolve those just as you normally would.
> >>>>
> >>>>Thinking about it, I guess you might have to redo conflict resolution
> >>>>again when
> >>>>you merge changes back to trunk.
> >>>Yeah, I wouldn't categorize that as 'just works'. Why should a user
> >>>have to resolve the same conflicts twice? That's an indication that
> >>>there are some changes *not* being tracked that should be.
> >
> >What svnmerge.py does is calculate "merged", "blocked", "phantom", and
> >"reflected" revisions, and subtract those from the list of revisions
> >requested
> >for merge (see the contrib/client-side/svnmerge/svnmerge.py:action_merge()
> >function). Issue #2897 is about proper handling of "reflected" revisions;
> >that is, revisions from the merge source which carry mergeinfo from the
> >merge
> >target as their payload.
> >
> >There are two potential flavors of reflected revisions:
> >
> >a) "Merging revisions", which themselves also carry mergeinfo.
> >b) "Merged revisions", which carry no mergeinfo (a leaf node in a merge
> >DAG).
> >
> >In Subversion's core Merge Tracking, we've decided that (a) requires
> >additional parents in the DAG to properly represent, and currently punt by
> >repeating merges in this case for the sake of correctness. The plan has
> >been to address this post-1.5. (b) is what Kamesh has been working on, and
> >is something that needs to be addressed before releasing 1.5. Without (a),
> >we're still in *much* better shape than in pre-1.5 releases; you can avoid
> >specifying revision ranges when performing merges, and the only repeated
> >merges you hit are when performing cyclic merging (M -> F -> M).
> >
> >svnmerge.py makes no distinction between these two types of reflected
> >revisions, instead filtering out both (a) and (b), which can miss merging
> >changes when pushing a branch which has been kept in sync with a mainline
> >back
> >into that mainline.
> >
> >>Normally, this hasn't been an issue in my work. In fact, I didn't even
> >>think this was much of an issue on any svnmerge.py discussion until this
> >>discussion came about, so the conflict resolution wasn't as painful as
> >>dealing with determining the revisions to merge back into the
> >>branch-source. This suggests that the conflict resolution hasn't been
> >>that painful for people.
> >...
> >
> >Indeed, svnmerge.py wasn't designed to handle cyclic merging; it's
> >--bidirectional option was bolted on after its initial design to offer some
> >degree of support.
> >
> >In my experience, svnmerge.py works best for keeping a feature branch in
> >sync with a mainline, and does a good job of this. However, its handling
> >of
> >cyclic merging is not something that I'd like to emulate.
...
> I find reflected merges very useful and we use them all the time and
> svnmerge.py has served people very well. The one thing svnmerge.py doesn't
> handle is transitive merges involving more than one location.
>
> The lack of conflict resolution that svnmerge.py is missing has not been
> painful for me for merging back into trunk. So 1.5 may not want to
> replicate its way of handling this, but it does it works very well.

I can see it working quite well in situations where the conflict resolution
required by the supression of merging reflected revisions is minor (that's
certainly been my experience as well!). In the case where conflict resolution
is a large portion of the merge, and may not be handled by the original
developers (certainly not my preference, but many large shops I've spoken
with follow this process), this behavior varies from onerous to downright
dangerous (e.g. due to content entirely missed by the merge).