[issue483] mq does not work under windows with gnu-win32 patch

[Patrick Mézard]

Chris Mason wrote:
> On Sat, Jan 20, 2007 at 10:35:48AM +0000, Patrick Mézard wrote:
> I need to push out a few win32 fixes, 

I applied Shun-Ichi diffutils.c patch, and replaced os.sep by '/' in 
patch.selectfile (diffs seem to be generated with normalized file 
names). Do you see anything else to correct ?

> but the repos here should work
> better.  They do not use gpatch, but process the diffs internally:
> 
> http://oss.oracle.com/mercurial/mason/hg-mpatch

It works with the cases I described in issue483.
Thank you, implementing patch in mercurial is definitely a good thing!

Still, I think we are doctoring the working dir/revlog mismatch in the 
win32text case only, without addressing the whole issue. Let's use the 
issue483 test case again with the following changes:

# f1 and f2 are now LF-only files
f1 = """a\nb\nc"""
f2 = """a\nd\nc"""

# .hgrc contains:
"""
[encode]
*.txt = dumbencode:
[decode]
*.txt = dumbdecode:
"""
That is I only want to use win32text for well defined files.

With this configuration, the test still executes correctly but f is now 
CR-LF after qpush.

What happens is reading patchfile and hunks in text mode is equivalent 
to forcing LF == CRLF for every input file. Which is true if win32text 
is set/unset globally and peoples edit their file in CRLF mode.

The good news is your design makes it easy to plug encoding filters at 
the right places without more cost than the filters themselves (since 
the patched files are already fully loaded in memory): instead of 
reading patchfile lines with file().readlines(), what about using a 
util.encodedopener ? Would the patching code works with CR-LFs instead 
of single LFs ?

--
Patrick

Pure curiosity: any reason not to use os.makedirs() in 
patchfile.__init__() ? The loop on directory parts does not seem to 
handle the os.pardir case any better than makedirs. Is it for speed ?