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

[Reinstein, Shlomo]

I've also been very surprised by this behavior, having used CVS for a couple
of years now, as an admin of our CVS repository. I was able to generate a
tiny example that demonstrates this behavior, even for a single user working
on the same project, in two different working directories (and using the
same client machine and same server machine in both). I made a change in
working directory A, committed it, and at the time made a change to another
file in working directory B and was able to commit it without updating
first. After the commit in B, "cvs status" shows that the file I committed
from A needed patch, and vice versa. I even did that on a newly created
repository which contained only the small project that I just created.

I also checked that this strange behavior was not fixed in CVS 1.11.1p1. I
don't know about the newer versions (e.g., 1.15.1), I will check this as
well.

Yes, the CVS server box is the only computer that accesses the repository
directly. All use the same CVS server box. I've also tried using different
server machines to verify that the problem was not with the specific CVS
server box we were using, and the same behavior happened in the other server
machines as well.

What's wrong with the repository being on NFS? Isn't that the case with most
CVS repositories? I didn't know there can be problems between an NFS client
and server being on different platforms, but I bet that the machine on which
the repository is located is also a Linux machine.

Shlomo

-----Original Message-----
From: Eric Siegerman [mailto:address@hidden
Sent: Tuesday, February 18, 2003 7:16 PM
To: address@hidden
Subject: Re: Commit inconsistency: Up-to-date check did not fail though it
sho uld have !


On Tue, Feb 18, 2003 at 06:35:35PM +0200, Reinstein, Shlomo wrote:
> 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.

It's supposed to work as you expect, locally and client/server
both.  I'm very surprised by the behaviour you saw -- so
surprised that I can't help suspecting that something else was
going on, since I don't believe I've ever seen an up-to-date
check pass when it shouldn't.

> Technical details:
>   - User A works on Linux, using CVS client & server version
>     1.10.8.
>   - User B works on Windows 2000, using CVS client 1.10.7 and
>     server 1.10.8
>     (both users using the same CVS server machine, same version of CVS on
both
>     machines)

Umm, those are pretty old!  May I suggest upgrading to 1.11.5?
No guarantee that it'll help, but it couldn't hurt.

>   - The repository is on NFS.

You probably know which red flag that's raising for me :-)  But
from what you say above, it sounds as though only the one
CVS-server Linux box is accessing the repo directly (i.e. it's
the only NFS client to touch it).  If that's correct, it makes
things less worrisome -- but I suppose there still might be
interoperability problems between the Linux NFS client and your
NFS server if it's on a different platform.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
        - Leslie Lamport


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