Re: Subversion branch deltification policy is more space-hungry than CVS

On Wed, 2004-06-02 at 13:50, John Pybus wrote:
>> Only if people *are* getting bitten by this :-). We should first
>> make sure that this effect isn't lost in the noise of other
>> things.

> Reading the svn lists, people converting from CVS seem to think
> so.

If you've been following this thread, you should realize that cvs2svn
inefficiency is precisely the "noise of other things" which Karl is
referring to.

> If in case iii) the cost of accessing old nodes shared with trunk is
> acceptable, what is the benefit of storing fulltexts for the changed
> nodes even on long lived branches?

It means it's more efficient to work on a branch while the branch is
still being actively worked on.

But, really, the most important thing is that it flows naturally out of
the simplest implementation of deltification: walk some portion of the
node-rev's predecessor list and redeltify some number of predecessors
against the newly-committed node-rev.

Any other strategy is going to be significantly more complicated.
(Except for the FSFS strategy of making all deltas point backwards in
time. We could implement that in BDB with somewhat less code than we
have now. Existing repositories would become kind of weird, but they
would still work and be reasonable efficient even with a naive
implementation of the new strategy.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 20:26:56 2004