This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications?


Larry Hall wrote:
toscani@wideopenwest.com wrote:

Well, I take that back...someone pointed me to http://www.gigascale.org/softdevel/faq/23.html, which contains instructions for reinstalling CygWin with text mode set to DOS, which actually fixes the problem (the remount procedure didn't work, as is warned in the article). All I did was run the setup utility, selected DOS text mode, and selected the base/cygwin and devel/cvs packages for reinstallation...works like a charm now. The contents of this article might be good fodder for the FAQs. Cheers!

I'm glad you found a solution that works for you. However, I do not believe it to be a general solution.


I repeat, I cannot reproduce this problem. I am using all binary mounts -- **and always have**. This means that my local working directory contains files that do not have ^M's. Naturally, the files on the remote, linux-hosted repository do not have ^M's. No "translation" is needed, and no translation is performed. Checkouts, updates, diffs, in both anonymous :pserver: and authenticated ssh mode all work fine.


Neither cygwin nor ssh nor cvs is omniscient. If you introduce ^M's into the local working directory -- perhaps by using notepad? -- then naturally those will show up as diffs when compared against the server.


You can HIDE those ^M-derived diffs by setting the mount mode to 'DOS' -- but I wouldn't recommend it as a general solution unless you really know what you're doing, and what the ramifications are (even I do not claim to know ALL of the ramifications).


I'd suggest this is the wrong direction to head in this case for at least a few of reasons:

1. This hasn't really risen to the level of a FAQ.

  2. The problem is ill-defined at least and isn't shared by the vast
     majority.

  3. It's not at all clear that the problem isn't fixable if it were
     better understood.

Perhaps someone seeing this problem could spend a little more time with
it and see if a solution can be found that makes any documentation of
it unnecessary.  That would be a real big help.

Actually, I believe the problem here is the following:


originally, mount mode was binary. cvs checkout (over ssh) was performed. local working-dir files were non-^M.

-- and then something happened -- maybe notepad. Maybe the recent perl update with all of the PERLIO=xxxx mess caused automake/autoconf to behave funky and add ^M's. Maybe vi or xemacs was accidentally set to "dos" mode. But somehow, someway, some OTHER program introduced ^M's.

And the ssh/cvs/cygwin faithfully (with binary mounts) indicates those differences.

Now, this is NOT how cvs is advertised to work.

It is SUPPOSED to open the local files, strip off ^M's if there are any (*) and handle all communication with the server in "unix" mode. When appropriate (on a windows sytem, or on cygwin with dos mounts) then it should add the ^M's back when writing to disk. (**)

(*) when in "cvs binary" mode (e.g. don't replace keywords; distinct from *cygwin* binary or fopen("rb")/open(O_BINARY) mode), then this "smart line-ending translation" should not be done.

(**) when accessing a local repository (as distinct from a local working dir), then ALL on disk files are supposed to be stored in ^M-less mode. (except of course those that are in cvs -kb / -ko mode). "Repositories are always unixmode."
---


What I think this means, is that cvs takes great care to do for cygwin what cygwin is already doing -- which is what causes the conflict, because cygwin's translation and cvs's translation are stepping on each other.

I THINK cvs-on-cygwin should be modified to do the following:
1) Always open all on-disk files in binary (fopen(O_BINARY) open("rb"/"wb") ) mode. ALWAYS, regardless of "mount mode"


2) Use the "mount mode" to indicate whether *cvs* should turn on its internal translation stuff. E.g. "mount=dosmode" means "I'm a DOSish system, do the DOSish thing" when accessing the disk, "mount=unixmode" means "I'm a unixish system, do the unixish thing" when accessing the disk. (for working dirs only, because repositories are always unixmode)

3) ***IF*** the file in question is in cvs binary mode (-kb, -ko), then DON'T do translation stuff EVEN on DOSish systems (e.g. even if mount mode = DOS, don't try to translate. You really don't want to strip ^M's out of png or gif files...

In other words, I'm advocating basically (1) letting cvs "turn off" cygwin's mount mode stuff -- but (2) use the mount mode as a cue for whether to "turn on" cvs's internal translation stuff.

Blindly linking cvs.exe against -lbinmode will take care of (1) [a rather brute force option...I'd rather do it right eventually] but it will take more effort to do (2) correctly. And then we get to test. and test and test and test...

--
Chuck




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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]