Mail Archives: cygwin/2006/04/01/16:02:17
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/
- Raw text -