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

[Mark Hammond]

On 4/07/2009 11:20 AM, Nick Coghlan wrote:
>
> 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.

That sounds like it should work - presumably mention of this should go 
into the PEP.

(While that is great for Python, it is a shame I probably can't use the 
same strategy for other hg repos I care about as I don't have access to 
server side hooks - but that if off-topic for this list.)

> 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):

This *appears* to be correct at first glance, but in practice it doesn't 
interact well with wildcards specifications - particularly 
'**=cleverencode'.  I started a thread on the ML and submitted a patch a 
few months ago to fix this and it was accepted, but sadly it seemed to 
have dropped off the queue somewhere.  The patch now conflicts, and I've 
promised to resubmit it when I find time.  But even with that in place 
it doesn't address the more general problem that when only *some* 
developers use the extension - mixed mode files are still very possible, 
at which point win32text starts reporting enough spurious conflicts to 
become unusable for me.  Eg, doing a clean checkout of mozilla with 
win32text enabled results in a working tree with hundreds of files 
reporting every line in the file has changed.

It is worth noting that win32text also works on Linux, and that in 
theory, win32text should be able to allow Linux users to work seamlessly 
with a \r\n repo, in the same way it promises to allow Windows users to 
work with \n repos.  But in practice, it is simply never used by Linux 
developers, even in the hg core dev team.  Patches or comments regarding 
win32text are always met with "but no one here ever uses it".  If they 
did, and some of the core hg team tried to experiment with win32text and 
mixed line ending repos the problems would, I believe, become 
self-evident...

Cheers,

Mark