[Cvsnt] Next release features

[Tony Hoyle]

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.

> * When examining an entry in the RCS file, you can see if that change
> was part of a valid commit by looking up the matching changeset marker
> 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
of the head (the common case) as fast as possible.  If a commit fails
really CVS needs to rollback everything before the locks are released.
I thought it did that anyway (it does the modifications is a temporary
file then renames it after it has finished).

If the network drops before the commit succeeds then nothing will happen
anyway - the CVS protocol buffers every committed file locally before
performing the commit.  It won't be able to report the results to the
user but it shouldn't abort.

The only way I can see a partial commit happening is in case of hardware
failure, in which case you've got bigger problems :-)

Tony

_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt