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

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

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-08-09 22:02:18 CEST

William Uther <will+@cs.cmu.edu> writes:
> - If you set it on each file then you have to make an individual copy
> of each file on the server (you are already making these copies in the
> wc) - that copy will be stored as a diff and will have a compact
> representation.

It doesn't matter if we store the new nodes compactly or otherwise.
The point is, we're creating new nodes where we formerly didn't. The
O() of the operation has changed: it's now O(N), proportional to the
number of items in the copied tree, instead of O(1).

That's kind of a showstopper.

> I think my original proposal is reasonable. The (slightly)
> inefficient part is if you create a large subdir on a branch and then
> merge it into another line of dev. In this case things are still not
> that inefficient. The content diffs will all be zero length - In
> effect this is just storing a node with the svn:merge property for
> each file. This is exactly the information you need to store for each
> file. And this use case doesn't often happen with large trees anyway.

That "this use case doesn't often happen" argument never works :-).
If it happens often enough to to make the benefits beneficial, then it
also happens often enough to make the harms harmful.

If the piece of information is "Tree PATH1:REV1, and everything
underneath it, was copied recursively to destination PATH2:REV2",
that's a very small bit of information. To store it distributed
redundantly across multiple nodes may be formally correct, but I'm
hoping we can do better.


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:18:38 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.