[Python-Dev] Mercurial migration: help needed

[Mark Hammond]

[Adjusted the CCs...]

On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
> On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis"<martin at v.loewis.de>  wrote:
>> The second item is line conversion hooks. Dj Gilcrease has posted a
>> solution which he considers a hack himself. Mark Hammond has also
>> volunteered, but it seems some volunteer needs to be "in charge",
>> keeping track of a proposed solution until everybody agrees that it
>> is a good solution. It may be that two solutions are necessary: a
>> short-term one, that operates as a hook and has limitations, and
>> a long-term one, that improves the hook system of Mercurial to
>> implement the proper functionality (which then might get shipped
>> with Mercurial in a cross-platform manner).
>
>
> My solution is a hack because the hooks in Mercurial need to be
> modified to support it properly, I would be happy to help work on this
> as it is a situation I run into all the time in my own projects. I can
> never seem to get all the developers to enable the hooks, and one of
> them always commits with improper line endings =P

Maybe you can enumerate what you think needs to change in mercurial, 
then once we have a plan in place it will be clearer who can do what.

I'm resurrecting my patch to support a filter called 'none' (which is 
turning out to be harder than I thought).  Off the top of my head, it 
would the following would give us a pretty solid solution:

* Finish my patch for 'none' as a filter, so '**=cleverencode' can be 
reasonably used (currently you can't specify specific files *not* have 
cleverencode, making it unsuitable in practice without the concept of 
'none')

* Add support for versioned 'filter rules' - eg, /.hgfilters or similar.

* This might be pushing my luck, but: add 'defensive' support to core hg 
for this feature - if /.hgfilters exists, hg should refuse to operate on 
the working tree unless the win32text extension is enabled.

Note that this last point still leaves win32text optional for hg itself 
- but if the owner of a repository has explicitly 'opted in' for 
win32text support, hg can still assist in refusing to screw the tree. 
The hg user has the option of enabling that extension, declining to use 
that repository, or arguing with the owner of the repo about use of the 
feature in the first place.

Is there something I'm missing?  Or maybe a better way to have hg 
enforce a repository's policy while not inflicting pain on hg users who 
don't want to ever think about windows?

Cheers,

Mark