[PATCH] mq: fix patch names/paths mismatch under win32

[Patrick Mézard]

The issue I am trying to solve can be reproduced by running 
"test-mq-qrename" under Windows. What happens is renamed patches are 
referenced by their Windows path in "series" like "foo\bar", making all 
subsequent calls with unix-like names like "foo/bar" to fail.

Because series files may be exchanged it seemed better to enforce path 
names normalization rather than tolerate filesystems dependent synonyms. 
This behaviour should be documented but I don't know where to do that.

Besides, the reverse operation (patch name => patch path) is implicitely 
performed by the Win32 API. Maybe it should be made explicit.

Patrick Mezard wrote:
> # HG changeset patch
> # User Patrick Mezard <pmezard at gmail.com>
> # Date 1168732707 -3600
> # Node ID 133fe070c4946c78e873ac205c4bf3fea36af888
> # Parent  112e9c5051980f5f27410d645ec19d692aed26af
> mq: fix patch names/paths mismatch under win32.
> 
> Patch names are implicit relative unix paths. Under win32, paths can have
> several equivalent representations because of case-insensitivity and path
> separators tolerance. To avoid confusion and improve interoperability, patch
> names are normalized to unix style when generated by mq, or checked to be
> unix-style when passed to commands or read from the series file. Writing
> Windows relative paths in the series file will now abort.