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

[Reinstein, Shlomo]

This would be fine if CVS had consistent behavior when using a local
repository and when using client/server. Until a short time ago, we used to
work with a local repository (on a network drive), and we got used to that
behavior. Our set of scripts around CVS rely on this behavior.
Shlomo

-----Original Message-----
From: Brandon Craig Rhodes [mailto:address@hidden
Sent: Tuesday, February 18, 2003 3:52 PM
To: address@hidden
Subject: Re: Commit inconsistency: Up-to-date check did not fail though it
sho uld have !


"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


_______________________________________________
Info-cvs mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/info-cvs