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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
