RE: Commit inconsistency: Up-to-date check did not fail though it sho

[Reinstein, Shlomo]

No, B had done a "cvs commit" without specifying the files to commit on the
command-line. This is why it is so suprising for me. CVS with a local
repository does not let such commits take place, but the client/server does.
Shlomo

-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Tuesday, February 18, 2003 5:38 PM
To: Reinstein, Shlomo
Cc: address@hidden
Subject: Re: Commit inconsistency: Up-to-date check did not fail though it
sho


Reinstein, Shlomo writes:
> 
> - User A checks-out the latest version of project p.
> - User B checks-out the latest version of project p.
> - User A changes one of the files in p, and commits his changes to the
> repository.
> - User B changes one of the files in p (not the same file that user A
> changed).
> - User B commits his changes to p, without first updating his working
copy.
> Against all expectations, user B succeeds to commit even though his
working
> copy is not up to date, leading to an unstable latest version of the
project
> in the repository.

CVS only demands that what you're committing be up to date.  If B had
done a simple "cvs commit", then CVS would have examined the entire
directory and complained about the file modified by A being out of date.
Instead, B apparently commited just the file he had modified ("cvs
commit foo"), so CVS only checked that file, found it up to date, and
allowed the commit.

-Larry Jones

See, it all makes sense.  See?  See??  They never see. -- Calvin