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

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

From: <kfogel_at_collab.net>
Date: 2004-06-02 17:34:27 CEST

"Max Bowsher" <maxb@ukf.net> writes:
> kfogel@collab.net wrote:
> > My question is: is there reason to believe that, in practice, this
> > property of active Subversion branches is a significant factor in
> > increased repository size?
>
> It's not just _active_ branches, though. No space is saved when the branch
> ceases to be active, and becomes only historical record.

What I meant was, there will be no extra space used in the first
place, if the branch is *not* active. That is, just making the branch
doesn't cost you anything. It's when you start to use it that you get
the tip fulltexts, and even then you only get them for the files you
actually change, of course.

The extra fulltexts don't go away when you 'svn rm' the branch, nor
when you stop working on it, of course -- never meant to imply
otherwise.

> OK. So far, I've been viewing this as "we use more space than CVS, isn't
> that wrong?". I will stop considering the question from that viewpoint.
>
> If we are to deliberately make a different space/time tradeoff than CVS,
> then at very least there should be some documentation that we can point
> users who get bitten by this at, so they understand.

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.

> I'm willing to perform some experiments to try to quantify the size of the
> problem, but I will need some help deciding what to test.

I don't mean to sound snide by this at all, but: having a test for the
proposed problem should be equivalent to fully understanding the
problem in the first place. IOW, if we don't know exactly how to test
for the problem, then what exactly *is* the problem? A precise
description should be a blueprint for a test. If it's not, then maybe
the problem hasn't really been precisely described.

> Here is a scenario particularly worrying to me:
> * Suppose you refactor a piece of software on a branch. All you need is one
> change to some function, which then needs to have all its callsites changed,
> and you have many tiny changes scattered over many files. Each file gets
> stored as a fulltext, rather than a tiny diff.

Yup. This is probably the worst-case scenario.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 2 18:54:55 2004

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.