I've just compiled and tried CVS 1.11.5 -- same behavior. Up-to-date check
does not work correctly when using client/server.
Shlomo
-Original Message-
From: Reinstein, Shlomo
Sent: Sunday, February 23, 2003 12:49 PM
To: Guus Leeuw jr.
Cc: [EMAIL PROTECTED]
Subject: RE: Commit
Hi,
I have ran the test with the repo local to the CVS server, and it shows the
same behavior. Which brings me to the conclusion that the client/server
protocol does not function as expected. Here's the scenario: (Can be done by
the same user on the same machine)
1. Create the repository:
cvs -d
This happened with 1.10.8 and also with 1.11.1p1. No related fix has been
mentioned in the news file for CVS versions 1.12-1.15.
Shlomo
-Original Message-
From: Guus Leeuw jr. [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 23, 2003 12:07 PM
To: Reinstein, Shlomo
Cc: [EMAIL PROTECTED]
- 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.
User B is an idiot for not
On Wed, 19 Feb 2003, Ludvig Borgne wrote:
Just go to the highest relevant directory and type ``cvs ci'' with no
arguments, or at most a -m to specify the message.
Hmm, this is interesting. I have always been (and still am) of the
opinion that one should always commit individual files, and
On Wed, 19 Feb 2003, Fabian Cenedese wrote:
Well, I also commit single files for the same reasons (even if that makes
me an idiot too). But before committing I sure do a test/update if there
has anything changed in the repo. So I do the same as cvs ci on whole
sandbox, just manually.
I
Reinstein, Shlomo [EMAIL PROTECTED] 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
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
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
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
On Tue, Feb 18, 2003 at 08:37:12PM +0200, Reinstein, Shlomo wrote:
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.
Darn! I was really hoping that was it. Well, maybe it's fixed
in
Reinstein, Shlomo [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
- 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
Reinstein, Shlomo [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]...
- 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
13 matches
Mail list logo
