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

[Patrick Mézard]

Chris Mason wrote:
> On Sun, Jan 21, 2007 at 04:10:06PM +0100, Patrick Mézard wrote:
>> Chris Mason wrote:
>>> On Sat, Jan 20, 2007 at 10:35:48AM +0000, Patrick Mézard wrote:
>> 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 ?
> 
> The patching code shouldn't care about line endings.  The place you'll
> run into trouble is if the patch has LFs and the file is crlf or vice
> versa, although maybe the encoded opener can deal with it.
> 
> To be completely honest, my policy on windows is to let people who can
> test make the decisions.  I try not to break windows support but things
> work much better if windows users send patches for it.

Well, my point is this is not a Windows problem but a mismatch between 
encoding filters and mq. Windows is the first symptom because the first 
place where encoding filter performing global transformations are 
applied. I have queried #mercurial about intended filters use and some 
people talked about file encoding transformations. Let's suppose I have 
global filters converting from a local encoding in working dir to utf-8 
in revlog. diffs will be utf-8 but patch() will apply them on locally 
encoded files in the working dir. This is not a Windows-only issue.

User supplied patches are also impacted since they must be generated 
from the same source than mercurial diffs, that is utf-8 encoded files.

Now:
- Maybe filters are a mistake and should be avoided.
- Maybe encoding filters just do not mix with encoding filters in 
general. If people want to use MQ reliably, they must ensure that all 
filters they use do not make working files and revlog files incompatible 
from a diff point of view. A CVS encoding filter which rewrites keywords 
is such a non-intrusive filter. This is the currently undocumented state 
of affair.
- Maybe filters must be dealt with, but with the filter API, not with 
filter specific workarounds.

What Alexis made me realize is this issues extends to whatever generates 
and consumes diffs, like diff, export, import commands. I think two 
kinds of diffs are relevant:
1- revlog diffs because they can be exchanged between repositories not 
sharing the same working files representations like Windows to Unix repos.
2- working diffs because you can create and import them manually. They 
could not be exchanged.

It is not worth the pain to devise something like listing the filters 
applied at generation time (assuming it is even possible) to allow 
interoperability between both modes. What could be done though is 
tagging them as local/repo to generate warnings when they are applied 
incorrectly by mercurial.

Then diff generating/consuming commands could take a --local/--encoded 
parameter to drive diff interpretation as inputs or outputs.

Anyway, thank you for your work on mpatch, better to lose single-LF 
sometimes than just having a broken mq.

--
Patrick