On 16 Mar, Derek Robert Price wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED]'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/