Sorry for any confusion.
I understand the reason and contents of the .svn.
I am asking for help to get more information on the problem. The first
thing is if other people are experiencing/know about the problem. I did
try searching the archives but that didn't seem to get any hits so I
subscribed to the list. And lo and behold somebody else mentioned the
same problem.
In my experience, the reliability of the .svn/tmp manipulation seems to
be very unstable.
Yes, once our main trunk is setup, we can branch/copy smaller pieces out
(code/data at least) but I want one global version of the project that
can be checked out and all I'm trying to do is populate the repository
with this version. I am doing it in the following steps which I do not
think is very complex nor atypical.
Scenario: 2 Dumps of code and data from external source. We are taking
over development representing two significantly far apart versions of
the project.
Into trunk: 1st version.
Tagged
Branched into "vendor drop" type branch (call it drops)
Checked out branch in new workspace
Version 2 copied into workspace
Version 1 -> 2 Deleted files deleted, committed
Version 1 -> 2 added files added, committed
Version 1 -> 2 modified files committed
That went smoothly as I recall.
Now I want to merge those revisions, one by one, into trunk.
That is when the "fun" began.
This process took several days because of repeated failures, often at
the end of waiting several hours for data to be transferred.
In particular, the .svn/tmp problem is problematic because it caused me
to have to throw away that workspace which takes hours to repopulate.
In other words, single revision merges (both using tortoise or command
line), from a branch, into the trunk.
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:31:56 2006