Obsmarkers discovery: consider using the current experiment

[Pierre-Yves David]

Obsolescence Markers Discovery Experiment
=========================================

We are experimenting with a new protocol to discover common markers 
between local and remote repositories. This experiment is still at an 
early stage but is already raising better results than the previous 
version when usable. So we recommend using it when possible.

Why a new obsmarkers discovery experiment?
==========================================

The current protocol is too fragile (new markers on old changesets means 
many common markers won't be detected)  and lack proper detection of 
subsets (one cannot know if local have more of less markers than the 
remote).

The new protocol detect common markers at a finer level and will be able 
to properly detect common subsets (in the future).

(Once we'll be happy with the state of a protocol it will be implemented 
in core)

Should I use it?
================

Yes, you should use it as long as your repository has less than 100 000 
revisions. The current experiment perform better and has some cache 
implemented.

On larger repository, the current experiment is not in a usable state 
yet. To support them, we need to rewrites some naive implementation of a 
key part of the algorithm that currently trigger a topological sorting 
for the ancestors of each merges. This leads to N²-ish timing. This will 
eventually get fixed. I'll send another email when this happens.

Will it eat my data?
====================

No, this has been running on production set for multiple weeks and 
nothing bad has been reported. In addition, obsmarker discovery is just 
about finding common markers to avoid sending too many over the wire. No 
data can be eaten.

How do I turn it on?
====================

The current experiment is controled by a couple of config options. 
Different value are commended for client and server.

Client config:

   [experimental]
   # enable new discovery protocol
   # (needed on both client and server)
   obshashrange = yes
   # avoid cache warming after transaction
   # (recommended 'off' for developer repositories)
   obshashrange.warm-cache = no

Server config:

   [experimental]
   # enable new discovery protocol
   # (needed on both client and server)
   obshashrange = yes
   # warm the caches after each transaction
   # (recommended 'yes' for server (default))
   obshashrange.warm-cache = yes

In all cases, it is recommended to enable the blackbox extension to 
gather useful data about the experiment. It is shipped with Mercurial so 
no extra installs are needed.

     [extensions]
     blackbox =

(more details available in "hg help -e evolve")

When will this new protocol be used by default ?
=================================================

There are multiple large tasks to be done here. Improving the 
algorithms, better cache mechanism and format, support for subset 
detection, etc… This will continue to move forward in the coming months 
depending of the available manpower and funding.


-- 
Pierre-Yves David