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

Re: svn not atomic with file:/// access?

From: Paul Koning <Paul_Koning_at_dell.com>
Date: Tue, 26 Feb 2008 13:59:29 -0500

>>>>> "Andy" == Andy Levy <andy.levy_at_gmail.com> writes:

>> of course we'd like to use the most robust mechanism for access
>> and of course we'd prefer it if users can't delete the repository
>> but we're also trying to make Subversions performance palatable to
>> our user-base, which is proving to be a challenge..

 Andy> As I said in my earlier response, safety should take priority
 Andy> over speed when talking about a system like Subversion. There
 Andy> is a tradeoff that has to be made, but IMHO that analysis
 Andy> shouldn't include leaving the door open to have the entire
 Andy> repository deleted by an errant keystroke on the part of any
 Andy> user.

... or messed up. Deletion of a whole repository is easy to detect.
Grab a backup and you're back in business (minus some hours of work,
of course).

The nastier problem is a user error, or application/OS error, that
scribbles on the repository in a non-obvious way. That might leave
you with bad data, or a missing commit, or other issues. Depending on
the specifics, it might go undetected for a long time. Perhaps long
enough that you no longer have backups far enough back...

I always use svn:// access for everything, for a repository that's
well over 10 GB, the working directory tends to be several GB.
Checkout is a bit of a wait, but you only do that a few times per
year. The rest is quite acceptable. Worst case is about the same
speed as CVS, best case is much faster (and functionaly vastly
superior!)

       paul

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-26 20:05:59 CET

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.