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.
Brian Smith wrote: > Ah, yes, I forgot about that. In order to "ignore" the change you > actually have to do the reverse-diff to get back to the previous > version. But, I suppose that the head revisision could be corrupt due to > the same error that caused the commit to fail, so the reverse-diff > wouldn't be safe to perform automatically unless you can verify the > integrity of the RCS file (say, with an MD5 hash or something like > that). Plus, things are more complicated when working on a branch > because branches are stored as forward-diffs. So, it is more complicated > than I thought. Actually you can just call the routine that 'admin -o' uses, then it'll 'just work' (admin -o has issues but they'll need fixing anyway). The individual RCS files are updated completely atomically already - cvs is extremely resilient which is why you rarely hear of corrupt repositories. The HEAD revision will either be committed or not - the only way an individual file could be corrupted is if the IDE controller was writing dodgy data, which would most likely have trashed the FS anyway (assuming no bugs in the CVS backend, and I'm pretty sure there aren't any that bad). > But, the server could still do everything I mentioned before, but > instead of doing the rollback automatically, it could send a > warning/error back to the client notifying him that the file(s) > requested were not part of a fully-committed transaction. That would be > pretty helpful rather than silently sending back corrupt files. Only the whole commit is imcomplete, each file will be OK. I expect the warning will only scare people rather than help. Tony _______________________________________________ Cvsnt mailing list Cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs