Fixed in crew (439b1c35348a)

I can confirm that the given patch fixes the problem for me. I built a binary
using patch from GnuWin32 - I don't know if that is the version used in the
official binaries.

The patch seems logically correct to me. In my (naive) view, hg should work in
binary mode at all times internally, translating CRLF only when storing files
externally for the end user. This approach is the one taken by Subversion, and
in my experience works well.

Some people want to use the patched "--binary" version of hg with GNU win32.
Besides redirecting them to Andrei Vermel patches posted on the ml a couple of
month ago, I am attaching the trivial patch here. It might be faster to edit the
file manually rather than patching it.

Hello,

MQ behaviour is not consistent with encoding filters: hg produces diffs based on
files encoded versions while MQ apply them directly on the working directory,
which contains decoded versions. One manifestation of this is the use of MQ
under win32 with gnu-win32 patch utility.  Here are the result with different
combinations of win32text setup and --binary added to patch.patch() function:

test files pseudo-content:
f1 = """a\r\nb\r\nc"""
f2 = """a\r\nd\r\nc"""

pseudo-test script:
"""
hg init
cat ../f1 > f
hg commit -Am f1
cat ../f2 > f
hg commit -Am f2
hg qimport -r 1
hg qpop
hg qpush
cat f
"""

1. +win32text -binary => qpush fails
2. +win32text +binary => qpush succeeds, f is LF only
3. -win32text -binary => qpush fails
4. -win32text +binary => qpush succeeds, f is CR-LF

qpush failures come from hg diff generating binary diffs (at least diffs similar
to those of gnu-win32 diff with --binary) and patching them in non-binary mode.

Still, I think the problem is not with the patch utility but with the working
dir/revlog mismatch. The correct way to patch is to apply diffs on an encoded
version of working dir then decode the results back in working dir. I guess that
roundtripping on temporary files would be unacceptable for performance reasons
(are there similar issues in git ?). Maybe the incoming mpatch should take
encoding/decoding filters callbacks as arguments to avoid intermediate files.
This could introduce other problems since filters not always work in streaming mode.

Another solution would be to accept the situation as an MQ limitation and
document patch requirements and encoding filters impact thoroughly.