[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: Max Bowsher <maxb_at_ukf.net>
Date: 2004-05-26 23:53:06 CEST

John Peacock wrote:
> Max Bowsher wrote:
>
>> 5. Examine the repository. Observe that there are multiple fulltexts
stored
>> per file. One for HEAD of /trunk, one for HEAD of /branches/foo.
>
> Since "branch" is a concept that exists only in the mind of the developer,
> that makes sense. A copy of any file in the repository is a node copy
only
> until that file is changed, when it becomes a fully populated node, hence
a
> "second" fulltext. Unless you are saying that all copies with history
should
> be stored as a delta from the original, there is nothing odd about this
> revelation.
>
> For large repositories with lots of tags/branches, where the branches and
tags
> are largely unmodified copies, the space-savings (for node copies) should
> vastly outweigh any additional fulltexts for modified branch copies (with
> fulltexts).

Sorry, this is incorrect. CVS branching is cheap in diskspace too - just a
short piece of metadata per RCS file, marking the branchpoint. So, the
"space-savings for node copies", compared to CVS, are negligable. However,
since on first modification, svn creates a fulltext, whereas cvs creates a
delta, svn loses.

I guess I am saying that the use of deltification with copies needs to be
increased, if svn repository sizes are to compete with cvs.

> As I understand the cvs2svn issue, when a branch is created, the files are
> _not_ copied from the trunk, so you wind up having fulltexts for all
branch
> files, not just for modified branch files. That is a big problem.

Ignore cvs2svn. It's irrelevant to this discussion. It was merely the
discovery site for this problem. This is a problem for freshly started svn
repositories with no previous history, just as much as for converted ones.
(And the above paragraph about cvs2svn isn't actually correct, anyway.)

See my reply to ghudson for more.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 00:06:28 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.