On Friday, August 9, 2002, at 03:48 PM, Bill Tutt wrote:
>> 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.
>
> 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.
Remember that merges are already not O(1) time - the copy is already
made in your wc.
> 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).
> 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 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.
> 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*
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.
later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 9 22:34:38 2002