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]
Sub
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
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 b
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 file
> > - 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 fo
> "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 u
"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 v
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 1.1
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 th
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
> beha
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
-Ori
"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 sam
12 matches
Mail list logo
