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.
-K
---------------------------------------------------------------------
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