Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > 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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs > _______________________________________________ > cvsnt mailing list > cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook > http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs >