[Python-Dev] Mercurial migration: progress report (PEP 385)

[Nick Coghlan]

Mark Hammond wrote:
> On 4/07/2009 12:04 AM, Nick Coghlan wrote:
> The big problem I have with win32text is that the rules are not
> versioned, meaning we will rely on every (windows only?) developer
> manually enabling the win32text extension, then manually adding these
> rules to an unversioned hgrc file.  Should the rules change over time,
> we will need to communicate that to every developer.  Contrast this
> with, say, SVN, where the rule is a versioned property on the file.
> 
> Further, if a repo *already* has mixed line endings and the file doesn't
> appear in the rules, win32text makes *lots* of noise regarding existing
> line endings and to "review your rules before you commit."  In effect,
> it seems to me that win32text will only work effectively if *all*
> developers using a repo are using it, or none are, or other steps have
> been put in place to ensure \r\n line endings in the repo are otherwise
> impossible.  I've completely failed to use win32text on the mozilla hg
> repo for exactly this reason.

I didn't realise Mercurial didn't have a way for a repository to provide
versioned extension settings, but in this case I think using our own
server side hook can deal with the problem (either adding it to the
existing whitespace hook that checks for tab/space sanity in Python
files, or else as a separate hook that just checks line endings).

Such a hook should be able to base the determination of which files it
checks for \r\n line endings on a normal versioned file in the
repository. For everything that *isn't* mentioned in that file, the hook
would check that it had \n line endings.

I believe that would address both of your concerns:
  1. A server side hook means that the rules are enforced on everyone
regardless of whether they use win32text or not (e.g no Linux developers
corrupting a .dsp file by opening it and saving it with \n line endings)
  2. The server side hooks rules will be versioned, allowing people to
copy them to their hgrc file so that win32text will correctly handle the
line endings for them.

Also, on another read of the win32text instructions, I believe the
configuration actually *does* support negative filters, it just doesn't
explain them very well (it only mentions them in the context of
overriding default settings in the config file for a specific
repository). I think a .hgrc file along the following lines might do
what we want (I'm not developing on Windows though, so I haven't
actually tested it):

=============
[extensions]
hgext.win32text=

[encode]
# Encode files that don't contain NUL characters.
** = cleverencode:
# But leave Windows specific and known binary files alone
**.bat = !
**.sln = !
**.vcproj = !
**.vsprops = !
**.dps = !
**.dsw = !
**.wse = !
**.ico = !
**.bmp = !

[decode]
# Decode files that don't contain NUL characters.
** = cleverdecode:
# But leave Windows specific and known binary files alone
**.bat = !
**.sln = !
**.vcproj = !
**.vsprops = !
**.dps = !
**.dsw = !
**.wse = !
**.ico = !
**.bmp = !
=============

Assuming we can find settings that do what we want then a sample HGRC
file could easily be provided in the Misc directory alongside things
like python-mode.el.

An alternative to the above would be to store *everything* (even the
Windows specific files) in the repository with \n line endings (still
enforced by a server side hook), and then *require* that Windows users
run win32text with settings like the following:

=============
[extensions]
hgext.win32text=

[encode]
# Encode files that don't contain NUL characters.
** = cleverencode:
# But leave known binary files alone
**.ico = !
**.bmp = !

[decode]
# Decode files that don't contain NUL characters.
** = cleverdecode:
# But leave known binary files alone
**.ico = !
**.bmp = !
=============

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------