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.
Tony Hoyle wrote: > Brian Smith wrote: > >> * Everytime an RCS file is modified, that modification has to be stamped >> with a changeset marker, some identifier/number that uniquely identifies >> the commit. The same identifier thus gets written to every RCS file that >> is changed during a single commit, and no two commits will ever have the >> same changeset marker. > > I was thinking of something similar for rollback functionality (I was > bored :-)... if someone commits something stupid then they could do a > rollback of their last commit provided nobody else had committed > something that conflicted. Sure, a changeset marker is needed for many reasons. >> in the changeset log file. If the changeset log file doesn't contain the >> marker, then the entry must have been part of a non-committed change and >> so should be ignored/overwritten. > 'ignoring' an RCS entry isn't going to be easy. The only entry that is > stored in full is the head revision, which is designed to make checkout 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. 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. > The only way I can see a partial commit happening is in case of hardware > failure, in which case you've got bigger problems :-) :) Presumably, any kind of error that occurs during the time that the server is copying the files back to the client would cause a partial commit since the server likes to exit ASAP when an error occurs. The conditions that might trigger a partial commit including out-of-memory, any kind of file access failure (hardware or security related), out-of-disk, power failure, "oops I knocked the server off the shelf again", any kind of complete system crash, etc. - Brian _______________________________________________ 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