Binary installers work too, closing the issue again.

My fault. The fix is working.
When I try to inspect the diff output. I typed
python c:\hg\hg diff | gvim -
and try to find whether there are ^M character displayed. It turns out when
vim detected mixed "\n" and "\r\n". It automatically convert "\n" to "\r\n" and
then display ^M. The diff output I attached in previous report is generated by
typing :w command in vim instead of python c:\hg\hg diff > out.txt. So it
appears bug is not fixed. Sorry for the confusion.

With this fix. The header part of diff file will have "\n" line ending. The
context part whatever text line ending of original file. Mostly "\r\n" in
windows environment. It will get some editors confused, like vim. But I think it
will be fine, since the GNU patch.exe can handle this file with "--binary"
option. And hg import can also handle the diff output.

Here is my test scenario, WinXP SP2, python25+pywin32, python build of crew-tip
with VS 2003 (but not py2exe):

C:\dev\mercurial>hg init test
C:\dev\mercurial>cd test
C:\dev\mercurial\test>echo a > a
C:\dev\mercurial\test>hg ci -Am t
adding a
C:\dev\mercurial\test>echo b >> a
C:\dev\mercurial\test>echo c >> a
C:\dev\mercurial\test>hg diff > test-pmezard.diff

test-pmezard.diff is attached. All code lines ends in CRLF as expected. Maybe
this is related to the py2exe build. The binary stream magic is embedded in the
root hg script.

Here is the diff output attached.

a3fe91b4f6eb seems cannot fix it.

I did a pull from http://hg.intevation.org/mercurial/crew.
It has a3fe91b4f6eb.

Then did 
1. python setup.py build -c mingw32
2. python setup.py build -c mingw32 py2exe -b 1
3. In test folder, create a file test1.txt which has only one line text1.txt
4. checkin test1.txt
5. add test2.txt test3.txt two lines in test1.txt file
6. python c:\hg\hg diff 
7. The output is below. The first 4 lines have line ending "\r\n". The context
has line ending "\r\r\n".
8. "python c:\hg\hg version" shows Mercurial Distributed SCM (version a76395713691)

diff -r 3c5415e417d3 test1.txt
--- a/test1.txt	Sat Jan 12 13:51:54 2008 -0800
+++ b/test1.txt	Sat Jan 12 14:48:45 2008 -0800
@@ -1,1 +1,3 @@ test1.txt
 test1.txt

+test2.txt

+test3.txt

tangguo77: maybe you can try a binary installer built after a3fe91b4f6eb and
tell us if it solves your issue ?

This is a little C program I am using in windows environment to fix "hg diff"
and "hg qdiff" output before they can be used by unixutils patch.exe command.
Hope we don't need it anymore in 0.9.6 hg release.

Should be fixed in crew by a3fe91b4f6eb

This bug still appears in 0.95. It's problematic for Windows users because the 
Windows binary distribution can't be patched (and somewhat ironic since this is 
the only platform it's a problem for).

One workaround is to take the result of 'hg diff' and run it through the 
following Perl one-liner.

perl -pe "s/\015//" import.patch > import.corrected.patch

Because we're looking for 0D 0D 0A sequences, it would be preferable to use a 
sed sequence like s/\015\015\012/\015\012/, but stdio handling appears to be 
getting in the way; that sed pattern never matches for me. 

If anyone comes up with a better solution, please post it here.

this is also an issue with hg cat

Demoting to bug.

It looks like other work is being done on this issue in parallel; see this
recent posting from the Mercurial developer mailing list:

http://www.selenic.com/pipermail/mercurial-devel/2007-February/000900.html

Maybe you all could work together?  :)

This patch fixes 'hg diff' output for me but not 'hg export', where I still get
the CR-CR-LF line endings.

However, it seems this bug should be fixed at the same time as a related one in
'hg import'.  Without hacking mercurial.patch.patch to include --binary I can
import a "correct" patch (i.e., one with CR-LF line endings) but the output uses
LF endings.  With --binary, I can't import a "correct" patch any more, but an
CR-CR-LF one will import as just CR-LF and work fine.

Add test for this issue.

Here is a patch :
- util.set_binary() takes an argument to enable/disable binary mode
- a binaryfile() method returns an ui-based stream in binary mode to hide
set_binary calls and force people to cleanup.
- patch.diff() uses binaryfile() as fp instead of ui.

You're welcome, but my name's actually Larry.  :)  And thanks for letting me
know you could use setmode() on stdio in Python; another tool for my toolbox.

> If Mercurial were written in C, the most straightforward solution would be 
> to use _setmode() to manage the text/binary mode of stdout.  Like so:
> _setmode(_fileno(stdin), _O_BINARY);
> // print lines of diff
> _setmode(_fileno(stdin), _O_TEXT);

Thank you Lee, I did not know that, you just saved my day.

You can do that in lovely python also, setmode() is available through the msvcrt
module and it works fine on stdio streams.

I am having this exact problem with Mercurial 0.9.3, so it's not fixed.  But!  I
believe I can shed a whole lot of light on the subject.


The specific problem:
If you check in files with the DOS-style 0D 0A ("\r\n") EOL convention, and you
modify those files, and you run "hg diff" *on Windows*, the diff will OD OD OA
("\r\r\n") at the ends of all lines copied out of the aforementioned files. 
Lines of the output created entirely by Mercurial (e.g. "diff -r abcdabcdabcd -r
cdefcdefcdef Foo/bar.txt"), and lines copied from files that have the UNIX-style
0A ("\n") EOL convention, have proper OD OA line endings.


To reproduce:
1. Use a Windows machine.
2. Install stock Mercurial 0.9.3 from http://mercurial.berkwood.com/ .  In
particular, I did *not* tell it to do any EOL conversion, and I assume it isn't
doing any.
3. Create a repository (hg init) and check in a file with DOS-style (OD OA) EOL
convention (hg add, hg ci).
4. Modify that file.
5. hg diff > x

If you examine the file "x" in the hex mode of an editor (or whatnot) you'll see
OD OD OA at the end of every line copied from your file.

Note that you also get the same behavior with other commands that produce a
diff, like "hg incoming -p" and "hg outgoing -p".


The cause:
This is almost certainly because Mercurial is preserving the original EOL
characters from the file, and "stdio" is open in "text" mode.  When you
sys.stdout.write(line) and "line" contains an 0A, it will automatically prepend
it with an OD.


The solution:
If Mercurial were written in C, the most straightforward solution would be to
use _setmode() to manage the text/binary mode of stdout.  Like so:
_setmode(_fileno(stdin), _O_BINARY);
// print lines of diff
_setmode(_fileno(stdin), _O_TEXT);

Since Mercurial is written in lovely Python, I'm not sure what the best course
of action is.  Perhaps call string = string.replace("\r\n", "\n") when running
on Windows?  You could do it at any stage of the process, though if done when
reading the file in to do the diff you'd save a little memory and speed up diffs
everso-slightly.

the problem was resolved when i copied Mercurial.ini from
"E:\bin\mercurial\0.9\" to "C:\Documents and Settings\$USER\", thanks to vok for
his question about "hg debugconfig".

>Which windows version are you running on
winXP SP2
>Are you using the installer version?
yes, 0.8.1-4334be196f8d and 0.9
>hg debugconfig

I don' have this problem. 
1. Which windows version are you running on
2. Are you using the installer version?
3. What is the output, if you run 'hg debugconfig'?

it behaves good on linux

example:
+ aaaa

- bbb

+ cccc

instead of:
+ aaa
- bbb
+ ccc

such behavior is only in versions 0.8.1 and 0.9 but not in 0.8