Re: Commit inconsistency: Up-to-date check did not fail though it sho uld have !

[Brandon Craig Rhodes]

"Reinstein, Shlomo" <address@hidden> 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                                            address@hidden