[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: William Uther <will+_at_cs.cmu.edu>
Date: 2002-08-12 07:28:34 CEST

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.

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

> 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
(though I suspect you know a LITTLE bit more about this than me :).

> 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.

later,

\x/ill :-}

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 07:29:40 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.