[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.
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
- Re: Commit inconsistency: Up-to-date check did not fail though itsho uld have !,
Mike Castle <=