Re: cvs 1.11.17 in command line server mode, OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005, problem with binary files

[René Berber <r dot berber at computer dot org>]

Jay Abel wrote:
[snip]
> [jabel@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@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 variables
(your current example is completely different than the previous one).

> cvs -q -z5
> update -Pd
> 
> And when I take a way the compression option:
> 
> cvs -q
> update -Pd
> 
> I get the following:
> 
> [jabel@jabelxp][jabel/cvstemp] % cd CVSROOT
> [jabel@jabelxp][cvstemp/CVSROOT] % vi cvswrappers
> [jabel@jabelxp][cvstemp/CVSROOT] % cvs up
> unrecognized request `anged loginfo'
> [jabel@jabelxp][cvstemp/CVSROOT] %
> 
> 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:
> 
> [jabel@jabelxp][cvstemp/CVSROOT] % cvs up
> M cvswrappers
> [jabel@jabelxp][cvstemp/CVSROOT] %
> 
> and:
> 
> 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
> 
> 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 Cygwin).

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 it 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.
-- 
René 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/