> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
>
> Philip Martin <philip@codematters.co.uk> writes:
> > This is what Will wrote:
> >
> > > There is one detail that I think is important: If merge copies a
> > > directory that didn't exist in revA (ie the dir was added with
> > > history) then you want to add the merge property to each file
> > > individually. This does not affect the time complexity as all
those
> > > files are being copied into your working copy anyway.
> >
> > The files get copied into the working copy, but they will show up as
> > status copied-with-history and unmodified, so only the parent needs
to
> > be committed. If we set svn:merge on the files then the files will
> > need to be committed as well.
>
> Oh dear, yes. We should only set the property on the directory that
> was copied... But of course, that loses some of the usefulness of
> having the property at all, for example if we're in a subtree of that
> directory later and need to retrieve merge history...
>
> Which, now that I think about it, is what led me to the long-ago
> conclusion that this problem is not simple. William, thoughts?
>
Heh. Well, clearly this is just one more wrinkle in our lazy-ness ==
complication syndrome.
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.
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.
This implies:
* That we need someplace in the copy table to keep track of this
factoid.
I'd suggest keeping this fairly compact. We may/may not run into more of
these kinds of issues.
* Having an efficient storage location for this merge data is going to
be a good thing.
Once we have #2 decided on then we can get on with figuring out how we
want to store star merge information, and how we want to store ancestor
sets.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 21:48:49 2002