> 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
bunch
> > 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
their
> > 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
is
> updated when a file is changed. In particular, I was assuming that
the
> 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.
>
Indeed.
> > then we can get on with figuring out how we
> > want to store star merge information, and how we want to store
ancestor
> > 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
here.
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:
> >
> > 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
directories.
> Essentially option #2 is making a new type of "copy-with-history",
that
> is more "merge-with-history". It is correcting the semantic
difference
> I was pointing out previously.
>
It's still not going to change the svn log output for you though. :)
FYI,
Bill
---------------------------------------------------------------------
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