[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: John Peacock <jpeacock_at_rowman.com>
Date: 2004-05-27 02:57:20 CEST

Max Bowsher wrote:
> 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.

Except that conversion from cvs to svn (whatever the program used) is where the
effect is *most* noticable. Historically I believe that has been a byproduct of
the conversion process itself; if cvs2svn is better about making copies instead
of adding new files for branches (which is the goal, I know), that's wonderful.

But the number of fulltexts generated per branch is going to vary wildly among
various projects; in some cases the branch is going to be mostly node copies, in
others it might have lots of modified files. I don't think that you have
demonstrated that the use of fulltexts on copies is significant to outweigh the
performance gains by not having to regenerate the files on checkout from the deltas.

I fully and freely admit that fulltexts on modified copies will yield [slightly]
larger repositories. I just don't think you have demonstrated yet that it
matters in the grand scheme of things. And personally *I* am willing to trade
[some] diskspace for performance (which is where the current scheme comes from,
does it not?)...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 27 02:57:23 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.