To: cygwin AT cygwin DOT com
From: =?ISO-8859-1?Q?Ren=E9_Berber?= <r DOT berber AT computer DOT org>
Subject:  Re: cvs 1.11.17 in command line server mode, OpenSSH_4.3p2, OpenSSL  0.9.8a 11 Oct 2005, problem with binary files
Date:  Sat, 01 Apr 2006 15:01:47 -0600
Lines: 117
Message-ID: <e0mpnr$gob$1@sea.gmane.org>
References:  <004701c655bf$6ede1340$84017ece AT jabelxp>
Mime-Version:  1.0
Content-Type:  text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:  quoted-printable
User-Agent: Thunderbird 1.5 (Windows/20051201)
In-Reply-To: <004701c655bf$6ede1340$84017ece@jabelxp>
OpenPGP: url=hkp://random.sks.keyserver.penguin.de
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Jay Abel wrote:
[snip]
> [jabel AT jabelxp][cvstemp/CVSROOT] % cvs commit -m 'try again'
> Checking in cvswrappers;
> /home/spring2006/CVSROOT/cvswrappers,v  <--  cvswrappers
> new revision: 1.3; previous revision: 1.2
> done
> cvs commit: Rebuilding administrative file database
> [jabel AT jabelxp][cvstemp/CVSROOT] %

Good, that proves that you had write access to the CVSROOT part of the
repository (and /tmp which I forgot in my last message).

> Yes, I have the same login name on both the unix machine and the local
> machine, in the one case where I don't I use a Hosts entry in the
> .ssh/config file.  I have write access to the repository in all cases.

OK.

[snip]
> Now this may interest you.  I currently have the lines:

Where?  Why don't you keep things simple, if you want to prove that the cvs
server doesn't work then use a simple test case and try not to change varia=
bles
(your current example is completely different than the previous one).

> cvs -q -z5
> update -Pd
>=20
> And when I take a way the compression option:
>=20
> cvs -q
> update -Pd
>=20
> I get the following:
>=20
> [jabel AT jabelxp][jabel/cvstemp] % cd CVSROOT
> [jabel AT jabelxp][cvstemp/CVSROOT] % vi cvswrappers
> [jabel AT jabelxp][cvstemp/CVSROOT] % cvs up
> unrecognized request `anged loginfo'
> [jabel AT jabelxp][cvstemp/CVSROOT] %
>=20
> Now, forgive me for grasping at straws here, but doesn't that look like
> a message was truncated or that perhaps some data was lost, or that
> perhaps a random piece of the file was sent instead?

No.  cvs -z5 ... works fine for me, your output shows a major problem with =
the
cvs command you are using (corrupted memory).

> In any case, all I
> have to do is turn compression back on, and:
>=20
> [jabel AT jabelxp][cvstemp/CVSROOT] % cvs up
> M cvswrappers
> [jabel AT jabelxp][cvstemp/CVSROOT] %
>=20
> and:
>=20
> cvs commit -m 'try again'
> Checking in cvswrappers;
> /home/spring2006/CVSROOT/cvswrappers,v  <--  cvswrappers
> new revision: 1.4; previous revision: 1.3
> done
> cvs commit: Rebuilding administrative file database
>=20
> The earlier example was given with -z5 on, so it's not a simple matter
> of the communication link working when -z5 is on, and not working
> otherwise. More likely, there is another factor which depends on the
> specific stream.

Are all examples of the form "from unix to Cygwin" (because your previous
message had some trace output that was not from the cvs provided with Cygwi=
n).

If the client is unix, what version of cvs is used on the client?

Are you still using text mode mounts?

> Let's agree going forward that you'll stipulate I have read the faq,
> googled the problem, and that a real problem exists.

No, you are seeing a problem but if it cannot be duplicated then the only
problem is your report.

> I'll stipulate I
> shouldn't have offered any explanation, and I was obviously (foolishly)
> wrong to ask about the 'I' option.  Of course those directories are
> ignored, that's what I want to happen.

Is that what _you_ wanted?  The only thing we are seeing here is normal cvs
behaviour, if _you_ wanted something being ignored then you should define i=
t in
a cvsignore or .cvsignore, have you read the Cerderqvist manual?

> But the problem does exist.
> Sometimes CVS client and server running on the same machine can connect
> and complete the transaction. Sometimes they can't.

Prove it.

> It appears that the
> problem is dependent on the specific characters sent (file contents
> affect it, compression affects it) and not on any design weaknes, per
> se, of the protocol, connection, or machine setup.

Then it should be easy to replicate, and therefore prove.
--=20
Ren=E9 Berber


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/