bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: bug#4451: 23.1; EOL problems with vc-diff and cygwin
Date: Sun, 27 Sep 2009 21:08:12 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

>> One interesting thing is that his --binary output seems to indicate
>> that his file's revision 1.2 was using DOS-style EOLs wereas the
>> current version is using Unix-style EOLs.  So maybe that has
>> something to do with the problem, indeed.

> All revisions of the XML file _should_ have Unix-style EOLs.  I'm not
> 100% sure they have in the example I showed (I can't verify this
> before October, sorry).  But I had the very same symptoms with
> different XML files.

The reason why I think your file had DOS-style EOLs on revision 1.2 is
that the --binary diff you showed had ^M^M^J on the "old text" and just
^M^J on the "new text".

>> Also, of course it may also depend on the CVS version used on the
>> repository's server.
> The repository is on a mounted Windows share.

Could it be that the RCS files accessed this way get an accidental
LF->CRLF conversion done by the network-file-system?
Seems pretty unlikely.  But could you try and copy (part of) the
repository to a local directory and try the operation again, just to
rule out any funny business from this side?

> BTW, why does `=' (`cvs-mode-diff') from PCL-CVS mode handle EOLs
> different to VC?

Because cvs-mode-diff applies to several files and doesn't presume that
those files are probably currently visited in Emacs buffers, so it just
always relies on Emacs's auto-detection instead.  Sometimes it works
well, but in general it's not as good as what VC does (typically diffs
involving iso-2022 files in a "latin" locale don't decode the iso-2022
encoding).


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]