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

[Charles Wilson]

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/