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

[Mike Castle]

In article <address@hidden>,
Reinstein, Shlomo <address@hidden> wrote:
>- 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.

Hmm... originally I was wondering, "How would this create an unstable
latest version?"

The only scenario I can think of is where user B starts making use of a
function that user A has changed/removed, and that function had never been
used in that file before.

In any other case, the file that user B was changing would have to have
been modified by user A.

Correct?

As a side note, this state is easily achieved by using Perforce as well.
And, I would imagine, any number of other systems.  To be honest, this is
the first time I've ever heard of CVS working in this way.  But then, 99%
of my cvs usage is using client/server or single user using a single check
out.

Actually, I can't even find it in the documentation.  Could someone point
out to me where it says that CVS will complain about an Up-to-date check
for files not being checked in?

>From my point of view, complaining about unchanged files is a bug, not an
undocumented feature.

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc