This is the mail archive of the 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: CVS and CR, LF

  Charles> Christopher Faylor wrote:
  >> On Mon, Dec 24, 2001 at 08:46:23PM -0800, David Koski wrote:
  >>> You are correct about the mount points.  I mounted in binary
  >>> mode, then used cvs in bash and it now works correctly.  Setting
  >>> CYGWIN=binmode did not have the same effect.
  >> Nor should it.  CYGWIN=binmode does not affect files when the
  >> files can be determined via a mount point.

  Charles> Hmmm...I suppose this all means that I missed an open() or
  Charles> fopen() call somewhere in gdbm or cvs, and it needs to have
  Charles> the appropriate "O_BINARY" or "b" added.  

no, No, NO, NOOOOOOO... Please do not do this.  

The company I work for uses a CVS repository on Linux and pserver
authentication to support checkins from both Linux and Windows2000
machines running Cygwin with everything textmode mounted. 

While the user that originally reported the problem fixed it for his
situation, he did it in a way that directly contravenes the stated way
that CVS is supposed to work.

>From _Open Source Development with CVS_ by Karl Fogel, page 52 on CVS
and Binary Files:

    CVS has some special tricks for text files. For example, when
    it's working between a Unix repository and a Windows or Macintosh
    working copy, it converts file line endings appropriately for each
    platform.  For example, Unix convention is to use a linefeed (LF)
    only, whereas Windows expects a carriage return/linefeed (CRLF)
    sequence at the end of each line.  Thus, the files in a working
    copy on a Windows machine will have CRLF endings, but a working
    copy of the same project on a Unix machine will have LF endings
    (the repository itself is always stored in LF format).

Please note the parenthetical remark at the end of the above
paragraph!  This is the reason (along with disabling keyword
expansion) for the need for the -kb flag on CVS add commands of binary
files.  It prevents them from being munged by the line ending
conversion and keyword expansion.

The reason turning binary mode on worked for the user who reported the
problem is that under Unix, since CVS expects the files to already be
in LF only form, it doesn't do any EOL conversion, so when they
checked in files with Windows CRLF endings on Linux, they got into the
repository this way.  

In general this is not a desirable situation, although it works for
the reporting user.  It is a side-effect of the rather incomplete
support CVS has for these line ending conversions which cause us
enough trouble as it is when people accidentally checking from a
cygwin Windows box with the mounts setup incorrectly or copy a Windows
file over to a Linux machine and check it in without fixing the line
endings.  If the cygwin CVS client starts always checking in the files
as binary, all hope is lost...

  Charles> However, I'm nervous about making that sort of change even
  Charles> if I DO find one -- wouldn't that mess up folks who are
  Charles> happily using cvs with local working dirs on textmode
  Charles> mounts?  Or is that a non-existent class of users, and
  Charles> everybody using cvs is also using binary mode mounts?

  Charles> Can anybody who uses text mode local mounts birddog this
  Charles> for me?

I hope the above explanation covered the issue in enough detail.
Please let me know if you have more questions about how we are using
the cygwin CVS client or my understanding of how the CVS repository is
supposed to work.

    Thanks, Keith

Unsubscribe info:
Bug reporting:

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