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

RE: Recommendation for Solaris 10 verses Linux & RAID for Subversion Server?

From: Ralph Navarro <RNavarro_at_iperia.com>
Date: 2006-03-21 15:56:07 CET

Would you have had fewer chances of problems if you used svn: instead of
file: ? I am trying to find out if the svn:// protocol has better
checks to prevent repository corruption than file:///

Ralph Navarro
Cell..: 508-287-0190
Email.: RNavarro@iperia.com
-----Original Message-----
From: Nico Kadel-Garcia [mailto:nkadel@comcast.net]
Sent: Monday, March 20, 2006 8:48 PM
To: Ryan Schmidt; Ralph Navarro
Cc: Subversion List
Subject: Re: Recommendation for Solaris 10 verses Linux & RAID for
Subversion Server?

Ryan Schmidt wrote:
> On Mar 20, 2006, at 16:27, Ralph Navarro wrote:
>>> The far likelier cause of file loss is operator error, not disk
>>> failure in my experience, and it's a lot easier to recover the files
>>> from a read-only repository.
>> Interesting. Are you saying it is possible for an operator to
>> corrupt a
>> checked in version such that you can't use the main repository to get
>> the file? If so, is it more likely to happen with bdb or FSFS?
> All you need is one careless "rm -rf" by an administrator and it
> doesn't matter what kind of data you're talking about, it's gone, and
> your RAID won't help you there.

Especially with cron jobs: I've seen a core server get wiped out by a
carelessly written clean-up script that ran at 3:00 AM on Saturday
Fortunately for me, that happened two days *before* I started that job.
having the on-line mirror has saved my butt on a number of occasions,
as when I accidentally trashed a repository by bringing in new material
the "svn ci file:///path-to-repository localdir" command.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 21 16:07:56 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.