[Cvsnt] Next release features

Brian Smith brian-l-smith at uiowa.edu
Sun Mar 10 00:34:19 GMT 2002


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



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook