Re: Merge symmetry (was: Tree Conflicts with Subversion 1.7)

On Mon, 22 Aug 2011 12:38:40 +0000, Stefan Sperling wrote:
> On Fri, Aug 19, 2011 at 04:15:38PM +0200, Andreas Krey wrote:
...
> > Actually, merging is a symmetric operation. The tree (and copyfrom
> > info) resulting from a merge should be the same independent of in
> > which direction the merge is performed.
>
> I agree that symmetry is a nice-to-have property of a merge algorithm.

I actually think it is essential.

> But I would be totally happy with asymmetric results, as long as either
> result is well-defined and repeatable. I don't see why the behaviour
> of a merge algorithm must be symmetric.

Because a merge computes the addition of two changesets/diffs/however you
name that: The delta from branch point (or last merge point) to trunk,
and to branch head. I see no reason why the outcome should depend on
which side I choose as the base of the merge: addition is commutative.

Although the 'addition' part may be seen as wordplay, I'd like to see
a case where a merge could reasonably not be symmetric (barring cases
with conflicts, where the conflict presentation usually is unsymmetric).

> > In svn the metadata just looks
> > completely different depending on the direction of the merge. (It also
> > is different due to the necessity of --reintegrate.)
>
> Sounds like you are conflating the UI with the underlying design.

No, I meant that besides the symmetry issue svn the mergeinfo actually
encode different information depending on the direction of the merge.

> --reintegrate is a UI issue and has nothing to do with symmetry
> or correctness.

I still don't quite understand why exactly --reintegrate is necessary.

Is it just because 'svn merge ^/branch' once meant 'take all changes of
branch since the branch point and merge them into trunk', and it shall
still mean that so we need --reintegrate to look closer onto the merge
info to use the source of the last sync merge instead of the branch
point as merge base? (But then we would need a 'merge --sync' as well.)

If it's not that, I don't see how the necessity of --reintegrate is an
UI issue and not a result of a suboptimal mergeinfo design, along with
the deadness of a branch after reintegration.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800