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

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

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-10 00:21:10 CEST

> From: William Uther [mailto:will+@cs.cmu.edu]
> On Friday, August 9, 2002, at 03:48 PM, Bill Tutt wrote:
> >
> > There are two possible approaches.
> >
> > 1) We decide merges just aren't O(1).
> > i.e. we mark all of the children as copied-with-history
> > That's not so nice because it makes life complicated and creates a
> > of copies with just property changes.
> Remember that merges are already not O(1) time - the copy is already
> made in your wc.

What Karl said. We're talking about repository side, not WC side.

> > 2) We fold this wrinkle into our lazy mode of operation.
> > Specifically: Initial edits of copies that originate as the result
of a
> > merge need the merge-specific ancestor set information added to
> > ancestor set.
> >
> > I kind of like #2 myself.
> 2) is more complex, although I can see how this might be implemented.
> It is much less complex than 'inheritable properties' in general.
> You'd also need to be careful in this case that the right information
> updated when a file is changed. In particular, I was assuming that
> URLs I mentioned were the URL of the file that was merged, not the URL
> used in the command line (which might be an enclosing directory).

The WC representation of the data is going to be different than the
repository representation of the data if we pick #2.

> > Once we have #2 decided on
> hehe :). #2 is more space efficient, but significantly more complex.
> If it were me, I'd probably choose #1 under the 80-20 rule.
> We could do #1 now and change to #2 later. The change would require a
> dump/load, but would be backwards compatible...
> Hmm - If we went with #2 we'd have to alter the dump/load format.


> > then we can get on with figuring out how we
> > want to store star merge information, and how we want to store
> > sets.
> Um, how are these different from a series of pairwise merges?
> I kinda want to keep this change small so it makes it into 1.0.

Ancestor sets, are the repeated merge problem. Having a place to stick
merge predecessors, possibly multiple merge predecessors is what I mean

Star merges aren't any different from a series of pairwise merges
effectwise. They just record all of those merges in one step.

> > Alternatively, we could just for the short term have an alternative
> >
> > 3) Don't store copy-with-history on completely new directories in a
> merge.
> Oh, you mean revert the recent "merge should copy-with-history" patch?
> *evil grin*

No, just don't copy-with-history on a new directory. ;) i.e. keep the
good part with new files, but punt on the annoying part, new

> Essentially option #2 is making a new type of "copy-with-history",
> is more "merge-with-history". It is correcting the semantic
> I was pointing out previously.

It's still not going to change the svn log output for you though. :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 10 00:21:45 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.