[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mike Castle
Subject: Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
Date: Mon, 03 Mar 2003 11:14:58 -0800

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.


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

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.

     Mike Castle      address@hidden
    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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]