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

Jay Abel jabel@flex.com
Sat Apr 1 19:06:00 GMT 2006


Questions answered below:

>> $ cvs commit -m 'update wrappers'

> Did a message with the revision number appeared at this point?

Yes:

 [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] %

> If you run cvs through ssh the repository has to belong (or at least has 
> to be
writable) by the user (and/or group) that is logging in.  The same goes for
CVSROOT on the repository (the history log changes).  Since you don't show 
any
user id on your example that means the user you are logged as has to exist 
and
have the required privileges on jayabel.com (and on the other non-cygwin
machines you used).

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.

You were right to point out the 'I' message, I rarely use the import 
command, so perhaps I should have chosen a different example.

Now this may interest you.  I currently have the lines:

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?  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.

Let's agree going forward that you'll stipulate I have read the faq, googled 
the problem, and that a real problem exists.  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.  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.  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.

Jay Abel 


--
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/



More information about the Cygwin mailing list