[PATCH 2 of 2 V2] server: introduce a 'experimental.single-head-per-branch' option

Boris Feld boris.feld at octobus.net
Tue Nov 21 14:13:57 EST 2017


On Mon, 2017-11-20 at 16:14 -0500, Augie Fackler wrote:
> On Mon, Nov 20, 2017 at 06:15:22PM +0100, Boris Feld wrote:
> > # HG changeset patch
> > # User Boris Feld <boris.feld at octobus.net>
> > # Date 1510800762 -3600
> > #      Thu Nov 16 03:52:42 2017 +0100
> > # Node ID 2d706154205c1fbff7ad5baea90697c7848ad61c
> > # Parent  5312b5738172718b868c1ecfd28ada8d4d7e85de
> > # EXP-Topic single-heads
> > # Available At https://bitbucket.org/octobus/mercurial-devel/
> > #              hg pull https://bitbucket.org/octobus/mercurial-deve
> > l/ -r 2d706154205c
> > server: introduce a 'experimental.single-head-per-branch' option
> 
> Convince me this should be done like this rather than as an example
> hook? We've wanted example hooks in contrib/example-hooks for years,
> maybe this would be a good start.

We discussed the possibility to use a hook with Gregory, but found
several limitations which explains why we went with this approach
instead:
    
    - The performance impact. Having the code in Python meant it has
access to more data in a more efficient way.
    - We don't really want to promote the Python hook API much because
it uses the internal API.
    - No cross-compatibility issues like we could have with shell
scripts on Windows. And not all Mercurial installations on Windows have
access to a Python interpreter.
    - Named branch policy might really fit as standard hooks. However,
we can think of multiple "mode" that would not really fit well as
"hooks (see later in the email for details).

Gregory seemed ready to take this series except for UI considerations,
so we updated the series to put the config in experimental so we could
land it while we bikeshed about how to activate it and what is the best
form it should take.


This series is a start of an experimental travel to tune the behavior
of Mercurial in order to better support specific workflows. This series
starts with enforcing a single head but it's only a part of a bigger
plan. Here are the areas we already thought about that would receive
such tuning options:

named-branches:
   * current behavior
   * enforcing single heads
   * refuse any named branch (but default)

bookmarks:
   * current,
   * forbid any bookmarks,
   * request all heads to have a bookmark,

subrepositories:
   * allow all,
   * allow hg only
   * allow none

phases: (getting into topic territory)
   * publish all,
   * publish draft without topic,
   * refuse draft without topic,
   * publish none,

These settings have non-binary values, we are thinking about something
like:

   [repo-mode]
   named-branch = single-head
   
Or:

  [repo-mode]
  name-branch = disallow

We could try to "force" the value in the hooks section, but it would
feels awkward to us:
    
    [hooks]
    internals.name-branch.single-head = yes
    internals.name-branch.refuse = no

We want to add similar tunings to other areas. Each area will likely
have several modes. From our understanding of internal hooks, they
would be either enabled or disabled. This difference let us 

We think that having a dedicated section to that will be clearer. We
are not sure about the name yet, maybe 'constraints' or 'workflow'.
They should probably come with a requirement to prevent older clients
to break things.

The example above is to start a standalone discussion. We prefer to
have this series gets into core (under the experimental section) in the
meantime.


More information about the Mercurial-devel mailing list