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

Re: Space wasting

From: C.A.T.Magic <c.a.t.magic_at_gmx.at>
Date: 2004-03-08 16:54:40 CET

> > Why doesn't SVN use a single folder? Why does it need 9 subfolders?
> > Also, is the README.txt file or the empty-file really needed?
>
> To take it a step further, why not a single compressed file, something
like
> ".system.svn" that won't give grief to Windows .NET projects, will consume
> less disk space, and yes will stay hidden in *NIX boxen.
>
> --- Eric

I think if the filesystem wastes a lot of memory for small files thats a
problem
of the filesystem, not a problem of svn. If you don't like the space wasted,
for example just enable filesystem compression on NTFS.

I like it to have the files in the .svn folder to be human-readable.
If the .svn folder used some "proprietary compressed structure",
it would be very hard for shellscripts and custom applications
to access it's contents.

I Also prefer access speed over disk space - and compressed data
will impact speed a lot more than the increase in files does.

also note that the files in .svn are modified often and vary in size,
which leads to problems like fragmentation when using a single file.
the filesystem already contains well known mechanisms to prevent
such fragmentation. its not up to svn to reinvent that wheel :-)

but it is ofcourse true that it would for example be possible to use a
DB (e.g. BerkleyDB) to manage all the -local- .svn contents, too.
But I bet using a DB would consume -even-more- disk space.

another simpler --option could be to allow deletion of the duplicated WC
files from the .svn folder. if svn absolutely needs to access them it could
redownload the files from the repository on demand - like CVS does.
ofcourse that additional download will cost you a lot of time. I wouldn't
want to enable that 'feature'.

just my EUR 0.2 ;-)
:-)
====
c.a.t.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 8 16:54:53 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.