Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <3F00F718.2050509@cwilson.fastmail.fm> Date: Mon, 30 Jun 2003 22:51:04 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Fwd: Re: CygWin adding CRs, hurting CVS client/server communications? References: <3EFDF2A4 DOT 1070901 AT cwilson DOT fastmail DOT fm> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20030628103913 DOT 032d72c8 AT mail DOT dnv DOT wideopenwest DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20030628103913 DOT 032d72c8 AT mail DOT dnv DOT wideopenwest DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20030630185211 DOT 00ba9bc8 AT mail DOT dnv DOT wideopenwest DOT com> <3F00EA93 DOT 7060006 AT cygwin DOT com> In-Reply-To: <3F00EA93.7060006@cygwin.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Larry Hall wrote: > toscani AT wideopenwest DOT 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/