On Fri, Nov 11, 2011 at 11:31:55AM +0000, Philip Martin wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > Paul Burba <ptburba_at_gmail.com> writes:
> >
> >> Does this answer your question at all (or did I answer a different
> >> question ;-)
> >
> > That's the cyclic merge again. Storing the transitive mergeinfo makes
> > cyclic merge work in some circumstances but not in others. What we are
> > trying to determine is whether that is the only use for transitive
> > mergeinfo.
>
> A bit of confusion on my part, failing to recognise the difference
> between catch-up merge and a cherry-pick merge. Cyclic catch-up merges
> can lead to conflicts due to merge tracking limitations, and the
> transitive mergeinfo doesn't really help. But I can see that for
> cherry-pick merges the transitive mergeinfo will probably be useful in
> more cases.
I still wonder whether the cyclic merge problem can even be solved
in theory. I mean, given a change rX which is the result of merges
of "original" changes rA, rB, rC, and rD, merged across some arbitrary
number of branches, plus additional arbitrary changes for conflict
resolution thrown in, is there an algorithm to pick apart the change rX
into its constituent parts rA, rB, rC, rD, and conflict resolution changes?
If an algorithm can't do this, then a sane version control system
must flag a conflict and let a human resolve it.
I'm not saying that Subversion's current handling of these situations
is as good as it could be. But I doubt that focusing on fixing cyclic
merges is the right approach. Our problem right now is that we flag
conflicts where trivial resolutions exist. Subversion needs to get better
at resolving trivial conflicts at merge time, especially those involving
renames (it is already pretty good at everything not involving a rename).
I suspect that this is what other tools, like git, do a much better job
at right now. I think it is why people get the impression that git
is "better" at merging than Subversion. It is not. Rather, it is better
at resolving trivial conflicts.
Git has the same fundamental problem when it comes to cyclic merging.
In fact, git developers actively discourage their users from doing
cherry-picking because cherry-picked revisions throw a wrench into
their DAG-based merge-tracking functionality. So one could argue that
git's merge-tracking is broken because it doesn't support cherry-picking.
But again, that's besides the point. It is no more "broken" than
Subversion's merge-tracking, because a cyclic merge will always cause
spurious conflicts, in the general case.
Received on 2011-11-11 13:32:12 CET