Re: cvs problem under cygwin, cvs documentation

[luke dot kendall at cisra dot canon dot com dot au]

On 16 Mar, Derek Robert Price wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  luke.kendall@cisra.canon.com.au wrote:
>  
>  >Although we have a moderately good workaround (an old version of cvs
>  >compiled up), we have a long-standing problem with cvs in Cygwin that
>  >I'm  looking into finally.  We get responses like:
>  >
>  
>  My Cygwin compilation works fine and even passes the test suite using
>  :ext: & ssh to another machine running the CVS server, but my Cygwin
>  installation is set to use UNIX EOLs and not Windows.  I believe this
>  was a compile-time option.

Okay.  The message implies that the :ext: method will or may suffer the
problem, and that the :server: method is needed.

Perhaps the reason this isn't affecting more people is that our
configuration is unusual?  We keep the cvs archive on a big Unix
system, and the Windows machines don't operate on the archive directly,
most of them talk to the Unix machine via rsh to run cvs there, and
read the results down to the local machine.

>  >Ah, one other difference is that our /opt/bin/cvs version does not
>  >complain about CVSROOT starting with ":server:", so the real question
>  >may be: why doesn't the Cygwin version include that?
>  >
>  
>  I'm not sure, but I think whether the :server: method is compiled or not
>  might only be based on an #ifdef.  Check the windows-NT/* code in the
>  CVS source distribution.  The only reason :server: was supplied at all
>  for Windows was that Windows xomes with a broken RSH implementation,
>  hrm...  that performs some sort of EOL conversion...

Interesting.  Ah, and the Cygwin version isn't based on the Windows-NT
source code, of course!

>  Is it possible
>  that your Cygwin CVS is using the Windows RSH client rather than the
>  Cygwin RSH?

It's possible, yes.  I just tried to find out the answer,
by doing an strace cvs update, but it locked up doing an open of
/dev/tty so I couldn't enter my password, so it didn't get as far as
that.

I'll try renaming the Windows rsh and see what happens ...

Nope.  I moved it aside, and re-ran /usr/bin/cvs update and got the
same response:

$ /usr/bin/cvs update
luke@cvs.research.canon.com.au's password:
' from cvs serverng: unrecognized response `ok
cvs [update aborted]: received interrupt signal
Killed by signal 2.

That version of rsh was quite low in my PATH:

$ whiches rsh
/bin//rsh
/usr/bin/rsh
/bin/rsh
/cygdrive/c/WINDOWS/system32/rsh
/usr/bin/rsh

Oh, hang on ... after moving "rsh.exe" aside in there, next time
something tries to access the file (e.g. the "whiches" probe for its
existence), it gets re-created.  Windows XP "self-repair" magic, I
assume.  Grr.

I'm not sure what else to try.  I just tried removing
/cygdrive/c/WINDOWS/system32 from my PATH altogether, but it made no
difference.

>  Again, I've had few recent troubles with the Cygwin client under Windows
>  and it can pass the test suite in a variety of ways.  I once had
>  troubles mixing the Cygwin CVS with a Windows CVS in the same sandbox
>  since the Windows version was saving carriage returns into the CVS/Root
>  files which Cygwin would later interpret as part of the repository string.

I'd only expect that if Cygwin was installed with the "Use Unix line
endings" option.  We always turn that off, since it makes working on
files with both Cygwin utilities *and* Windows ones too painful.

You get the same problem if you mix cvs operations from different OS-es
(different in how they treat line endings).  We never check-in source
from one OS that was checked out from another, for that reason.

I assume that's what you're referring to?

BTW, does anyone know whether the settings of the CVSROOT environment
variable is supposed to be described in the man page?

luke


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