[Python-Dev] Mercurial migration: help needed (original) (raw)
Mark Hammond skippy.hammond at gmail.com
Fri Aug 21 09:16:18 CEST 2009
- Previous message: [Python-Dev] Mercurial migration: help needed
- Next message: [Python-Dev] Mercurial migration: help needed
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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
- Previous message: [Python-Dev] Mercurial migration: help needed
- Next message: [Python-Dev] Mercurial migration: help needed
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]