Line ending translation extension

[Mark Hammond]

On 6/09/2009 9:46 AM, Martin Geisler wrote:
> Hi people from python-devel, hi mercurial-devel
>
> There has been a long thread over on python-devel about how Mercurial
> can support something similar to the svn:eol-style property:
>
>    http://thread.gmane.org/gmane.comp.python.devel/106002/
>
> (I've Cc'ed a bunch of people from the thread. I hope that is okay.)
>
> The win32text extension already has the necessary filters, but I think
> it has an unfortunate name: it seems very Windows-centric whereas this
> problem is not particularly tied to Windows. The names of the filters
> are also strange to me ('cleverencode:' -- why the colon?).
>
> Another problem with win32text is that one must configured it again and
> again -- the settings are not stored in the repository.
>
> *Python people:* are there other problems with win32text? I don't use
>    it, so I wonder why you guys are not trying to improve that extension?

Of the problems, the main ones are:

* It appears designed to have identical semantics on Windows as 
non-windows.  As a result, it doesn't seem possible to have win32text 
configured identically on 2 operating systems, but have each OS use 
'native' line endings for all files under its control.

* It is, in a practical sense, an orphan.  For the above reason and 
possibly others, win32text is simply not used by anyone in the core hg 
team.  As a result all requests about win32text tend to fall on deaf 
ears and if prodded, the response is universally "sorry - can't help - 
don't run it".  It seems to me that almost all win32text questions to 
the hg-dev mailing list go unanswered.

> I think we need someone who uses Windows and who therefore cares about
> this issue -- as a Linux guy it's still difficult for me to see why this
> is such a problem, except for new files (but they are easy to correct as
> they pop up).

This has come up on the python-dev list, but I think the solution to 
this is easy - first, ensure the extension works correctly on 
non-windows platforms (which will be a requirement anyway IIUC, so the 
few rules which do *not* indicate native EOLs must still work on 
non-windows platforms.)  Secondly, use a repository to edit files where 
other than 'native' line endings are implemented.  This will force hg to 
perform conversions on Linux for most working-tree operations.  This 
should ensure that you can see the same pain Windows users see, and more 
importantly, will ensure that non-windows users can easily reproduce 
test cases reported by the bug-trackers etc - they will just need to 
'reverse' the line-ending specifications when reproducing on non-windows 
platforms.

> Personally, I would like Mercurial to have at least as good support for
> this as Subversion and other systems have. But I'm not going to drive
> the development, it's not really my itch. I just hope to kickstart it.

Me too - I first started trying to help out with this well over 6 months 
ago mainly for selfish reasons:

* Given Python's decision, I'd like to move some of my personal python 
related repos to hg, but some of these can regularly expect use by 
Windows users.

* I use some 3rd party hg repositories - some of them huge, such as 
mozilla - and am yet to meet *a single one* I work with regularly with 
clean line endings.  IMO this is undesirable, and blaming Windows or 
Windows users is somewhat disingenuous - but I can't see how to help 
prevent this in the current situation.

Cheers,

Mark