Note that the quotation (and hence answer) is out of context...
I was not asking why there are .svn folders everywhere, I was asking why
an update that changes one localized directory apparently causes every
.svn folder to be touched/modified. Considering the repository can have
tens of thousands of folders, that's quite a price to pay.
A quick scan of the book doesn't seem to answer this question directly.
Nor does it seem to give any information about the .svn/tmp issue.
Peter
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2006Q1@ryandesign.com]
Sent: Tuesday, March 14, 2006 3:12 PM
To: Peter Yamamoto
Cc: Subversion List
Subject: Re: 'svn cleanup' no workie
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:59:06 2006