This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]