[Top][All Lists]

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

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

From: Reiner Steib
Subject: bug#4451: 23.1; EOL problems with vc-diff and cygwin
Date: Mon, 05 Oct 2009 18:07:53 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.1.5)

Eli Zaretskii wrote:

What I'd like to see is where in Emacs sources we examine the output
we get from Diff, and where and why we err as to what EOL format
should be used for decoding that output.

`vc-coding-system-for-diff' is called 2 times when I do `C-x v ='

vc-diff-internal(t (CVS ("c:/Users/x123456/tmp/check-out/K3.xml")) nil nil t)
  vc-diff(nil t)
  call-interactively(vc-diff nil nil)

  vc-cvs-diff(("c:/Users/x123456/tmp/check-out/K3.xml") nil nil "*vc-diff*")
apply(vc-cvs-diff (("c:/Users/x123456/tmp/check-out/K3.xml") nil nil "*vc-diff*")) vc-call-backend(CVS diff ("c:/Users/x123456/tmp/check-out/K3.xml") nil nil "*vc-diff*") vc-diff-internal(t (CVS ("c:/Users/x123456/tmp/check-out/K3.xml")) nil nil t)
  vc-diff(nil t)
  call-interactively(vc-diff nil nil)

One possibility for this mistake might be that Diff produces
inconsistent EOL format in its output, for example if Diff or its VC
front-end outputs some headers that have Unix EOLs and then the actual
diffs with DOS EOLs.

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").  However, in my workflow I overwrite the file
with a Unix EOL file (exported from some application), do modifications,
diffs and check it in.

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

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.

Stefan Monnier wrote:
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?

I copied the repository file to a local drive and also used local drive
working copy (drive c:).  But that doesn't make any difference.

Bye, Reiner

[1] $ cvs --version

Concurrent Versions System (CVS) 1.11.22 (client)

Copyright (C) 2006 Free Software Foundation, Inc.

reply via email to

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