[Python-Dev] Mercurial migration: help needed

Mark Hammond skippy.hammond at gmail.com
Sat Aug 22 02:56:36 CEST 2009

On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
> On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease<digitalxero at gmail.com>  wrote:
>> I like this, though maybe .hgextensions since it would contain
>> versioned rules and the actual required extension. The extra sub
>> directories are not really required IMHO, you just have a hgrc file
>> that works the same as the local hgrc file except it only looks in the
>> .hgextensions directory for the correct extension so for python we
>> could have something like
>> [extensions]
>> format_enforcer =
> Enabling extensions in a versioned file is not going to fly.

I like Stephen and Nick's discussion higher in this thread, but wonder 
if some middle ground couldn't work.

Instead of [extensions], just have a place to list the required 
extensions - eg;

Something like ~/.hgrules having:

[config]  # or maybe [rules] ?
required_extensions = win32text, some_pydev_specific_extension

{rules for encoding}

some_custom_property_for_our_custom_ext = 1

... etc ...
(Note I am not proposing we need out own pydev_specific_extension, I 
just included it here to try and show the more general concept)

This way you aren't *enabling* extensions in this versioned file, just 
listing rules about what extensions must be enabled.  From core hg's 
POV, it doesn't care if the required extensions relate to windows line 
endings or re-encoding images - it just honours the wishes of the repo 

 From earlier in the thread, Dirkjan writes:

 > The [concept of hg enforing required extensions] might indeed be
 > hard to get into the core, but seems like a good idea to try.

 From my POV, this would be required in some form or another before such 
a scheme could actually work.  Without it we end up with an improved 
win32text (good!) but in practice still have the same problems we have 
discussed in this thread which would make it unsuitable for us who 
actually try and use it, particularly as a general solution for projects 
with any kind of windows focus or community.

Given you are a core hg committer and well known in the community, would 
you be willing to start a thread with the hg developers about this 
issue?  If something like this can't get into the core, I will drop any 
expectations of it becoming a viable general solution for windows 
focused projects, so would limit the work I am willing to invest to the 
commitments I've made here.



More information about the Python-Dev mailing list