py-mercurial

[Daniel Ericsson]

On 6 maj 2012, at 21:14, Sean Farley wrote:

>> I didn't go into the fact that there are some ports depending on mercurial and I wanted to give those a target to depend on that included the python version. But with 24, 25 being on the way out and most ports defaulting to 27 it probably will be an issue that goes away.
> 
> I have about half of this work already done in my own local repo.
> Would you like me to finish this up and create a ticket(s)?

Go for it!

<snip>

> 
>> $ port list depends_lib:mercurial
>> hg-forest                      @20101118       devel/hg-forest
>> py-mercurial_keyring           @0.5.0          python/py-mercurial_keyring
>> py24-hgsvn                     @0.1.9          python/py-hgsvn
>> py25-hgsvn                     @0.1.9          python/py-hgsvn
>> py26-hggit                     @0.3.1          python/py26-hggit
>> py26-hgsvn                     @0.1.9          python/py-hgsvn
>> py27-hggit                     @0.3.1          python/py27-hggit
>> py27-hgsubversion              @1.4            python/py27-hgsubversion
>> py27-hgsvn                     @0.1.9          python/py-hgsvn
>> tortoisehg                     @2.1.2          devel/tortoisehg
> 
> The forest extension is mostly dead, having been replaced with subrepos:
> 
> http://mercurial.selenic.com/wiki/ForestExtension
> 
> so I would recommend removing it. Same with hgsvn (replaced_by hgsubversion).

hg-forest isn't even compatible with mercurial 2.x, without a maintainer or a replacing port can we just remove it? or do we need a grace period as the guide says?

I do think the replaced_by is a bit heavy handed if it works like explained in the guide, swapping out peoples hgsvn install for hgsubversion on upgrade feels wrong even though hgsubversion might be a better approach. Is there a precedent for stopping new installs of a port but not swapping out peoples existing installs?

-- Daniel