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