Enabling evolution bitbucket side (or any other server)

Gregory Szorc gregory.szorc at gmail.com
Sun Mar 16 18:49:43 CDT 2014


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.

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.

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.


More information about the Mercurial-devel mailing list