setup for cvs client to strip carriage returns

[wi]

Quick questions, explanations follow:

- Exactly what happens when setup.exe sets "default text file type" to unix?  
  - Does reinstalling with a different setting change the effect completely?
- Can I get cygwin cvs to remove and add \r on upload\download
  by using mount to tag my local repository as text mode?

I'm trying to debug 
- why my files are checked into cvs with ^M (\r)
  and how to avoid this in the future
- what I need to do to clean up the situation 
  if some of the files in the global repository have \r
  (in particular: do I need to check any affected files in
   correctly, or can I rely on the next checkin to
   clean up the problem?)

I've looked through faq/docs/email (relevant links below)
but have not found a complete answer.  My model of the correct behavior
doesn't seem to track reality :). I'd prefer (in order):
a) the cvs server to strip any incoming \r\n to \n, leaving
   it to DOS cvs clients to prefix \r to \n (or tell server to); or
b) the cvs client to strip/add as needed, or
c) the local editor, diff, etc. to ignore \r and not add on write.

But...
a) is for gnu/cvshome.org to answer
c) is a royal pain (er, I mean it's a support problem)
b) seems to be how it's handled, though not consistently.

As I understand it, instead of having the cvs server enforce the stripping
of \r\n to \n,[1] it's left to the windows-based cvs clients.  I think
the right thing is always to add/strip \r\n combinations, but I'm 
hearing that the cygwin cvs client is instead trying to operate in binary 
mode (and hence preserve the \r\n?)[2].  Is that right?

This problem might be more prevalent than reported if/since editors are 
masking it by handling the adding/stripping themselves and it only shows
up where users operate on the same files from windows and unix.  It might 
only show up as cvs diff's (i.e., sans -b flag) reporting excess changes.[3]

I'd like the cvs client to manage the \r\n as follows [4]:
  (a) prefix \r to \n in files when downloaded to local repository
      from global repository, only if \r is not already a prefix,
  (b) remove \r prefix from \r\n in files when uploaded to global 
      repository from local, including all \r before \n.
That would mean a windows cvs client would work when the local repository
is either windows or unix-based.  The alternative of preserving the \r
essentially make the files less usable on unix (file-)systems.
  
I thought that was how it worked, but I have no basis for this 
except hearsay.  I think that would track user expectations. 

Before reading that the cvs client uses binary mode, I thought I could
force this behavior by setting the mount point of the local repository 
to text mode (or having the repository on an unmounted path), because 
of the way that \r is handled by cygwin.
- filtering for \r during file-read and file-write is handled
  on a per-application basis according to these rules:
  - a file will be filtered if it is opened in text mode
  - a file will be opened in text mode if any of the following
    are true:
    - the file system call (via cygwin) specifies text mode
    - the file is marked as a text file (how?)
    - the file is not marked as binary mode, and
      - the mount point is marked for text mode 
        (using the mount command), or
      - the path is not associated with a mount point,
        and so enjoys the default behavior, which is text; unless
      - CYGWIN variable is set up to default to binary mode (binmode)

So now you understand the basis for my questions.  I'm concerned that
"unix mode" means "binary" is the default mode for all files, and I'm not
sure that updating the CYGWIN variable would help there (or where the
various settings are stored - .profile?)  I'm also concerned that the 
binary read/write is not overridable via mount-modes because the cvs client
was written using binary flags in the file IO calls.  Lastly, I'd prefer
this behavior to be the default and/or explicitly specifiable rather 
than inferred from settings which may be legitimate for other reasons.

Thanks for plowing through a long post, and (in advance) for any help.
Wes

[1] I'd prefer the cvs server to enforce this (on request), to avoid 
    depending on every windows cvs client to be implemented correctly,
    or requiring every client (e.g., on Linux) handle windows linefeeds.

[2] http://cygwin.com/ml/cygwin/2001-12/msg01277.html

[3] http://cygwin.com/ml/cygwin/2001-12/msg01089.html

[4] This behavior might be conditioned on the "unix mode" flag not
    being set (i.e., no need) or the local repository files not
    being in binary mode (marked, binary mount, or CYGWIN variable).
    However, I'd much prefer an explicit cvs client flag or environment 
    variable to these, since there are good reasons to set those
    modes unrelated to cvs behavior.

------------------------ references
- cygwin handles \r re-writing when using text mode
  http://cygwin.com/cygwin-ug-net/using-textbinary.html

- use mount to force binmode 
  http://cygwin.com/ml/cygwin/2001-12/msg01146.html
  http://cygwin.com/cygwin-ug-net/using.html#MOUNT-TABLE

- binmode works for cvs (but to _preserve_ \r?)
  http://cygwin.com/ml/cygwin/2001-12/msg01137.html

- mount mode take precedence over CYGWIN variable setting
  http://cygwin.com/ml/cygwin/2001-12/msg01146.html  

- cvs developer may have not specified binary mode on
  some cvs file call - asking for test help, and concerned
  about forcing binary mode on text mode users
  http://cygwin.com/ml/cygwin/2001-12/msg01277.html

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/