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

Re: 'svn cleanup' no workie

From: Ryan Schmidt <subversion-2006Q1_at_ryandesign.com>
Date: 2006-03-15 00:12:16 CET

On Mar 14, 2006, at 22:39, Peter Yamamoto wrote:

> (!!!??? WHY all the .svn folders in the whole damn workspace!?!)

http://svnbook.red-bean.com/en/1.1/ch02s03.html#svn-ch-2-sect-3.1

"A working copy also contains some extra files, created and
maintained by Subversion, to help it carry out these commands. In
particular, each directory in your working copy contains a
subdirectory named .svn, also known as the working copy
administrative directory. The files in each administrative directory
help Subversion recognize which files contain unpublished changes,
and which files are out-of-date with respect to others' work."

The files need to go somewhere. Going into each directory is a) the
same as CVS, and b) convenient because it means that any directory in
your working copy is itself a complete and valid working copy.

It doesn't have to be that way. svk, which is built on Subversion,
stores its working copies in a different way that doesn't litter each
directory with a .svn directory. I believe fsvs [2], which also bases
on Subversion, also stores it differently.

> Once again, I'm going to have to blow away a ~30Gb workspace (*2 for
> .svn poop) and start all over again.

The pristine copy of the data, which consumes again as much space as
the data, is there for the simple reason that it lets you determine
if files are changed by doing a purely local operation, and not
having to contact the repository server. It also means that
Subversion can send your changes to the server as a diff, rather than
as entire files. Both of these are supposed to make it faster than
CVS. Admittedly 30GB is a lot to have in a single working copy, and
duplicating that is probably not pleasant.

Someone was working on a way to have the pristine copy compressed.
There's another request open to make the pristine copy optional, and
have Subversion compare the data against the repository server, like
CVS, to save on local disk space.

While you're working out the best way to set up and use your
repository, perhaps you could work on just a subset of this data, to
make it faster?

> I am really having second thoughts about using subversion as a
> practical
> version control solution at this point.

Please know that your problems are not typical. Most people are able
to use Subversion successfully by reading the book and following the
examples. I'm not sure what's going wrong in your case. I'm sure
there's a way to solve it, I'm afraid I just haven't worked out what
the problem is yet. :-/

[1] http://svk.elixus.org/
[2] http://fsvs.tigris.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 15 00:13:05 2006

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.