Enabling evolution bitbucket side (or any other server)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sun Mar 16 18:54:24 CDT 2014



On 03/16/2014 04:49 PM, Gregory Szorc wrote:
> On 3/16/14, 2:49 PM, Pierre-Yves David wrote:
>> Hi Brodie,
>> (cc the list as it may interest other people)
>>
>> Early last week I update the `simple4server.py` extensions to make sure:
>>
>> - it was properly tested,
>> - it was working with mercurial 2.9.1,
>> - it had a way to disable the feature on a repo basis.
>>
>> It should now be ready for deployment at bitbucket as discussed during
>> the mini-sprint.
>>
>> Where is it?
>> ============
>>
>> This current state of the extension live in the head of default of the
>> mutable history repo:
>>
>> repo:      https://bitbucket.org/marmoute/mutable-history/
>> Branch:    default
>> file:      hgext/simple4server.py
>>
>> You update to the current default head. (its currently
>> 6cb81dbb95163806f31522a17f01cff25daf9708 for the record)
>>
>> make sure you use simple4server.py. Evolve.py focus on client side
>> capability and is not compatible with 2.9.1 in default.
>>
>> Enabling obsolescence marker on a repo basis
>> ============================================
>>
>> simple4server will turn the evolution feature on. Making core mercurial
>> happy to create and transmit obsolescence marker.
>>
>> The current the obsolescence marker exchanges used in core mercurial is
>> very slow and ineffective. You do not want to blindy turn it on for all
>> repo on bitbucket.
>>
>> So now simple4server.py includes a config switch to disable the
>> capabilities to exchange obsolescence server side.
>>
>>    [__temporary__]
>>    advertiseobsolete=False
>>
>> The default is still "true" so you want to set it to False in your
>> global config. And offer a check box to enable it in the repo config (as
>> you did for publishing repo).
>>
>> At some point mercurial core will have a descent strategy for exchanging
>> the markers. We'll be able drop this option and enable it for all repo
>> at that point.  Ihope to make quick progress regarding obsolescence
>> exchange in the next few months.
>>
>> Ping me if you have any additional question.
>
> Awesome!
>
> I do have one nit though.
>
> It's annoying that any changes to the wire protocol seemingly need to
> have a global extension and per-repo disabling (such as evolve here). I
> /think/ this is due to the wire protocol "subsystem" being initialized
> very early in Mercurial startup, before the per-repo hgrc is read. Or
> maybe it has to do with capabilities being defined in a shared data
> structure (that lives across multiple hgweb requests). I can't remember.

No it's only due to the global evolution switch in mercurial core. 
Mercurial core is evolution aware for more than a year and a half now. 
But everything is disabled through a process wide boolean (for 
simplicity sake).

So here we need an extension to inhibit -core- feature on a repo basis.

> There are a number of use cases where I may only want to change
> capabilities on a subset of repos *without* having to munge the hgrc of
> every other repo to disable that capability/wire protocol change.
> Testing remotefilelog is one such use case.

Extension should not spill to other repo. You can probably report this 
as a bug when meet.

> I was curious if you or anyone else has looked into making it easier for
> wire protocol changes to be opt in per repo rather than global enable
> with per repo opt out. That would make it much, much easier to test this
> and other wire protocol changing extensions.

Yes, see related series currently in review.

-- 
Pierre-Yves


More information about the Mercurial-devel mailing list