For anyone who is interested, I got jCVS to talk to my CVS server over SSH. It turns out that the problem is line endings (y'know the old CRLF vs. LF thing). Apparently by default when you open a process (like SSH), stdin and stdout are opened in DOS text mode, and so Cygwin translates every LF it sees to a CRLF pair. This means that when jCVS reads the server response from SSH, the stream has all these extra CR characters in it, which confuse the hell out of it. This isn't a problem with the pserver or RSH modes because jCVS opens those sockets directly. I'm not completely sure why it's not a problem for the command-line cvs; I figure it must just be that when the *nix system calls used by cvs.exe are invoked Cygwin assumes that they should be handled in the *nix way (it uses the traditional vfork/exec stuff). The solution (sort of) is to tell Cygwin to default to binary mode for all file handles. You do this by setting the CYGWIN environment variable to "binmode". Just put: CYGWIN=binmode in your autoexec.bat for win95/98/ME or just go into Control Panel->System->Advanced->Environment Variables and add the variable there for NT/2000. The downside of CYGWIN=binmode, if you use Cygwin for other things, is that it will occasionally open text files in binary mode, causing other problems. Most GNU utilities are written for maximal portability and seem to do the right thing (i.e. they explicitly open files with appropriate binary or text mode flags). To make this work, it's still necessary to turn GZIP off, although WinCVS works just fine with compression on, so this is a flaw in jCVS, not some additional, deeper problem. From the behavior it looks to me like a buffering issue; I don't think jCVS is getting the request to the server actually pushed out the door, so when it blocks waiting for the response it waits forever 'cause the server's still waiting for the request. I'm going to take a look and see if I can fix it. Shawn.
Description: S/MIME Cryptographic Signature