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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 18, 2003 5:38 PM To: Reinstein, Shlomo Cc: [EMAIL PROTECTED] 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
