RoadMap for Obsolete Marker

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 11 15:40:50 CDT 2012


This afternoon Matt, David, Augie and I talked about Obsolete Markers. MWe
mostly talk about their Definition, Storage and Exchange.


The current goal is to get Obsolete Marker into core as "experimental" and
"disable" them by default until they are more mature.

* "Experimental" means that people should not complain if they get in trouble using it.

* "Disabled" means that operation that currently strip changeset will continue
  to strip them except configured explicitly to create obsolete marker.  By
  default repository will also claims to not support obsolete changeset over the
  wire.

In parallel I'll update my experimental extensions to keep implementing more
advance feature so that people can play with it.

The Plan is to add features in the following order:

I) Marker Storage
-------------------------

    The idea is to be able to have Obsolete Marker in a repository:

    a) Define the obsolete marker content,

    b) Implement an obsolete marker storage,

    c) Add a command that create obsolete marker.

    I'll send another email dedicated to this topic soon.

II) Exchange
-------------------------

    Finding and efficient way to exchange Obsolete marker between repository is
    complete.

    * Obsolete markers are not related to each other as changeset are.

    * You can't never safely delete Obsolete Marker so the amount of them grow with
      the repository.

    A solution adding "generation number" to obsolete marker may have been
    found. I'll write another email with detail later.

===== After this Step ============================================================
= People should be able to try it in real word (using my experimental extensions =
= for all missing feature)                                                       =
==================================================================================

III) Various adaptation
-------------------------

A lot of work is necessary to make the mercurial code base aware of Obsolete
markers and friendly with them.

a) Mercurial should hide and ignore "extinct" changeset in the UI by default. A
   Changelog wrapper should do it and we need it for secret changeset too.

b) history rewritting command should be able to land (we experimental switch is
   on)

c) Properly detect (not solve) error case (unstability, conflict etc) and
display error message.

IV) Works on conflict resolution
---------------------------------------

This is about having a command able to solve errors situation detected in the
previous phases.

===== After this Step ========================================================
= We may consider removing the experimental label and enable obsolete marker =
= creation by default                                                        =
==============================================================================

V) History rewriting UI
---------------------------------------

This about improving options to rewrite history (eg):

* Rebase into core

* Histedit

* amend changeset with children

* command to move changeser (hg rebase -Dr $1 -d .)

* ...


VI) Add Various Garbage collections options
-------------------------------------------

Now that we do not strip changeset anymore, having garbage collection option
would be great.



This ROADMAP is of course open to discussion. I hope to get at least point I
and II into core before 2.3.

-- 
Pierre-Yves David

http://www.logilab.fr/




More information about the Mercurial-devel mailing list