[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Saving merge history (was: Re: merge should copy-with-history)

From: <brane_at_xbc.nu>
Date: 2002-08-12 13:50:48 CEST

Quoting William Uther <will+@cs.cmu.edu>:

> On Sunday, August 11, 2002, at 09:03 PM, Branko Čibej wrote:
> > Apart from merges and becoming O(N)? Well, I think it's a nice idea,
> > but rather nave and deserves to be scuttled on its maiden voyage, like
> > the Vasa. :-)
> >
> > What we should ask ourselves is this: What do we want merge history
> > for? The simple answer is, "To avoid the repeated-merge problem." Now,
> > while this solution tells us which versions of which files contributed
> > to a file's contents, it doesn't give us enough information to
> > implement real changesets.
> Another reason to save merge history: getting the logs right. See Issue
> #820.

Sure. I'm just not convinced they're wrong. :-)

> The proposed change saves enough information to re-create the original
> merge command to svn. What else does 'real changesets' require?

You have to be able to track individual diff hunks, not just whole files. For
example, after a merge each diff hunk in the merge candidates can be in one of
the following states:

   - merged: the hunk didn't cause a conflict, and the
               whole hunk is now in the merge target.
   - ignored: the hunk didn't cause a conflict, but was
               not included in the merge target.
   - modified: the hunk didn't cause a conflict, but was
               modified in the merge target.
   - accepted: the hunk caused a conflict, but the whole
               hunk was chosen as the merge result.
   - rejected: the hunk caused a conflict, but the hunk
               from the other merge target was chosen.
   - resolved: the hunk caused a conflict, which was resolved
               by modifying (manually merging) both merge hunks.

The (merged, ignored) and (accepted, rejected) pairs are complementary, and the
set of states is symmetric WRT the conflicted/not conflicted boundary, yielding
the following table:

                | use all | use none | use part
    no conflict | merged | ignored | modified
    conflict | accepted | rejected | resolved

What you propose only gives you "merged" and "ignored" info for whole file contents.

> > That simply isn't good enough. We know (at least I know :-) that we'll
> > have to at least simulate true changeset knowledge in order to get
> > variance-adjusted merging. To do that, we'll need a way to track
> > indivdual diff hunks, their relatedness and collisions. I have a
> strong
> > feeling that this cannot be done efficiently in properties. The word
> > that comes to my mind is "micro-branches", but that's all it is for
> > now -- just a word, without much substance behind it. I suspect the
> > schema modification that gives us efficient changeset management will
> > also give us efficient distributed repositories, and a _lot_ of
> thought
> > has to go into that (Bill, don't get hit by a car yet! :-).
> I'll have to take your word for this... I've also been thinking about
> distributed repositories, and I can see that you may be right in that it
> is related to merge history. I don't see that tracking individual diff
> hunks is necessary though - just a modified form of the delta combiner

Oh, right. You're absolutely right. A changeset engine _is_ a modified form of
the delta combiner. The trouble is that the "just" happens to hide a slightly
huge amount of work. :-)

> (though I suspect you know a LITTLE bit more about this than me :).

Heh, I wish I did... I'm learning along the way, too.

> > If we implemented this proposal now, we'd just have to rip it out
> > later. Right now, our repeated-merge problem is no worse than CVS's,
> > and is a bit better in places -- the possible exception is our use of
> > diff3 instead of an (the?) integrated diff library. It think that is
> > sufficient for 1.0.
> If you don't save merge history now, even given that you don't use it in
> 1.0, then you are losing information. The logs on those copied dirs are
> never going to be correct if you don't save the merge information now.
> If there is an easy way to save that information, and even if we end up
> re-formatting it later, saving it would seem to be a good thing.

Hm, that is a good point. In fact, I'm inclined to say this point is more
important than getting 'svn log' "right" (for some definition of "right" -- I
think it's more right to show too many logs than to show too few, witch is so
not right that it's wrong :-).

Let's talk about this a bit more, then.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 13:51:46 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.