Well, I don't know that I "can't do that", considering that it works just great for me. Though the editor that I'm using on my Win2k box (SNiFF+) understands UNIX line endings and has an option to save as Win/DOS, Mac, or UNIX line endings (which is of course what I have selected). So my code files get edited properly.
I assume that the client CVS program actually contacts the server CVS program when a checkout or checkin is done. So...presumably it is the server CVS that handles the writing of the administrative files, so I would assume the integrity of the line endings would stay intact (UNIX style). Am I assuming too much? Unfortunately the two-sandbox thing doesn't work with the tools I'm using. But since I seem to be perfectly functional if I choose to do one or the other (local or remote), but not both, things workout fine. I just wanted to know if there was a way I could do both (have my cake and eat it too). See...the other two people in my development team will only use Win2k but as I'm very much a Linux person I'd rather have the option of doing both. But if not, oh well. The biggest problem was that I tried getting each piece up and running independently first than tried to get them to work together. Usually is a great idea to make sure two parts work by themselves first. Who knew? :) - Steve > -----Original Message----- > From: Kaz Kylheku [mailto:kaz@;footprints.net]On Behalf Of Kaz Kylheku > Sent: Thursday, October 31, 2002 4:12 PM > To: Steve deRosier > Cc: Shankar Unni; CVS Discussion List > Subject: Re: pserver login problem to Linux from Win2k > > > On Thu, 31 Oct 2002, Steve deRosier wrote: > > > Here's what is happening: > > 1. J: is a networked drive connected to my home directory on our Linux > > server via Samba > > You can't do that, because Linux and Windows don't agree on the > representation of text files. This affects the treatment of text > documents on update and commit, and also the representation of the CVS/ > administrative files. > > So even if you solve the location non-transparency problem by using > a CVSROOT that works everywhere, you still have this problem. > > > New question: Is there an easy way to fix this problem, so I can > > transparently use CVS in the same working directory both remotely and > > locally? > > You can simply maintain two separate sandboxes. To propagate changes > from one to the other, commit in one, and update in the other. > _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs