[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-09 21:48:16 CEST

> 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

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.