bug#4451: 23.1; EOL problems with vc-diff and cygwin

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 05 Oct 2009 18:07:53 +0200
> From: Reiner Steib <reiner.steib@gmx.de>
> Cc: 4451@emacsbugs.donarmstrong.com, monnier@iro.umontreal.ca
> 
> The repository file (K3.xml,v) has Unix EOLs.  But if I do a fresh
> checkout, I get a file K3.xml with DOS EOLs (I think this is the usual
> behavoir of the Windows cvs binaries[1] for text files unless you
> specify the switch "-ko").

Yes, that's normal behavior of the ported CVS.

> However, in my workflow I overwrite the file with a Unix EOL file
> (exported from some application)

Why are you doing that, and what is that ``some application'' which
converts the DOS EOLs into Unix?

> Probably this conversion is also the reason that "cvs diff --binary"
> outputs "^M^M$" for the old file and "^M$" for the new file.  "cvs diff"
> outputs consitent DOS EOLs (both diff markers and the text):
> 
> $ cvs diff SK3.xml | cat --show-all | grep -F -v '^M' | wc -l

It sounds like your port of CVS assumes that text files have DOS
EOLs.  If you violate that assumption, it produces badly formatted
files, as far as EOL is concerned, and all hell will break loose on
you; Emacs showing the ugly ^M characters is just one of the
symptoms.

> > Another possibility is that somewhere along the chain of processing
> > the output, we force EOL conversion to be Unix-style, instead of
> > detecting EOLs dynamically, or maybe even forcing it to DOS (if we
> > have clear evidence for doing the latter).
> 
> `vc-coding-system-for-diff' returns `utf-8-unix' in both calls.

Because the file is already visited in an Emacs buffer, I presume, and
vc-coding-system-for-diff uses that.

So I agree with Stefan that you should simply not overwrite the
checked-out file with Unix EOLs.  We could install the change
suggested by Stefan (based on this analysis, I no longer object to
it), but I'm quite sure this won't be the end of your trouble.  For
example, Patch will most probably fail to apply the diffs, because
they have DOS EOLs while the source file has Unix EOLs.  This means
that CVS merges will also fail.  Etc., etc. -- that way lies madness.

If you really want Unix EOLs, you will have to hack CVS to use binary
I/O.  (I think you can force that by using some special Cygwin options
when ``mounting'' the volume, but don't ask me for details, because I
don't use Cygwin.)

Thanks.