"Reinstein, Shlomo" <[EMAIL PROTECTED]> 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.
I believe that this behavior is intentional - CVS places on the programmer responsibility for knowing which files must remain in some consistent state in committed revisions of the project. The problem with CVS attempting to prevent this situation manually is that CVS, which in its defense knows very little about the meaning of your project's file's organization, does not know which files need to be updated before allowing user B to commit. In our project, for example, it would be sufficient before committing this_module.sql to make sure that this_module.test.py (its test suite) was up-to-date as well. In another project CVS might need to check that the entire current working directory were up-to-date before committing; and in your case perhaps the parent directory and its sub-directories need to become involved as well. Instead, all of this is probably best done with a simple CVS that knows only about updating and committing things, and developers who supplement CVS's default behavior with scripts that support their project's correctness. -- Brandon Craig Rhodes http://www.rhodesmill.org/brandon Georgia Tech [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
