[cvsnt] Repository Robustness

[carl at membersonlysoftware.com]

I have had a couple of problems with a CVS repository when using an old, unstable 
client against a new CVSNT server.  I really don't know what happened, but two files 
ended up loosing history.  

This occurred  from failures associated with one computer that was miss behaving.

I was able to go into the RCS file and patch it together quite well ( and I didn't know 
anything about the RCS file format before starting).

As a comparison.  I have seen a Visual Source safe repository become so corrupted 
that history on many files was unuseable.  And source safe used a database back end 
(Jet engine) at that time.

The nice thing about a reverse-delta approach is that the latest changes are most likely 
to be correct.

Carl

On 6 Feb 2004 at 16:11, Shawn Haigh wrote:

> Thank you for your prompt and very informative reply... I am planning on
> using the standard client/server configuration, suppose that there was a
> disk corruption or failure..? would I still be able to recover to the
> last commit?  For example some other databases use a journal file
> (usually on an other volume) to recover all the changes since the last
> full backup of the database. Is there a similar feature with CVSNT if
> not, would it be in the future?
> 
> - Shawn
> 
> -----Original Message-----
> From: Tony Hoyle [mailto:tmh at nodomain.org] 
> Sent: February 6, 2004 3:57 PM
> To: cvsnt at cvsnt.org
> Subject: Re: [cvsnt] Repository Robustness
> 
> Shawn Haigh wrote:
> > I was just having a discussion with some colleagues about the scenario
> > in which a repository would become corrupt. First of all, based on
> > everyone's wide range of experience have you ever heard of this
> > happening? Second, what would be the best way to keep a running backup
> > of the repository.
> > 
> Assuming you're using a standard client/server configuration, it's 
> pretty hard to corrupt a repository unless there's a corruption of the 
> disk itself.  All file file level operations are atomic, so even if 
> there's a power failure your repository will still be OK (you might have
> 
> a partial commit, but I don't consider that 'corrupt' as you can recover
> 
> it by doing an update/commit on the client).
> 
> Over file shares it's a lot more muddy - there have been reports of 
> corruption using them, although rare.  I don't recommend that 
> configuration for that reason (amongst others).
> 
> One scenario that could be called 'corrupt' is sharing sandboxes - 
> checkout on an NT machine and checkin on a Unix machine.  You'll get the
> 
> CR/LF pairs stored in the RCS file and the next checkout on NT will 
> convert that to CR/LF/LF, etc.  The rule of thumb is don't share 
> sandboxes across platforms (but if you must, never mix clients).
> 
> Tony
> 
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> _______________________________________________
> cvsnt mailing list
> cvsnt at cvsnt.org
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
>