Mail Archives: cygwin/2003/06/30/22:53:42
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/
- Raw text -