StatesPlan - a draft of the sprint discussion about liquid hg

Pierre-Yves David pierre-yves.david at
Thu May 12 07:47:09 CDT 2011

On Mon, May 09, 2011 at 09:32:54AM -0500, Matt Mackall wrote:

> >     (2) `A` is kept in the death set but treated as it's children (liquid/local).
> I'm not sure what this means. A changeset is only in precisely one state
> at a time.

I have trouble to see "dead" as a state. More explanation below.

> > As I understand it, The current design exchange the set of all dead changeset
> > will be exchanged throught pushkey in the form: a set of <node> entries.
> > 
> > If we change this a little bit to be; set of (<node>{0,2},<node>) tuples, it
> > fit both the deadset usage (in the form set of ((),<node>)) and obsolete
> > stuff.
> Uh, no. The point of this document is to lay out why a coherent notion
> of 'states' exists... and why obsolete records and abandon records do
> not fit into it. The semantics of dead changesets are distinct from
> obsolete changesets, even if they are quite similar.

I think that laying out a coherent notion of states is a good idea. But I don't
really like making "dead" part of the State concept. I have the feeling that
the "dead" concept is close enough to the obsolete one to behave the same way and
to be handle the same way by mercurial. Making "dead" a state, will result in a
slightly different behaviour and handling. To have the equivalent of "dead"
with the obsolete stuff we are going to need a **new** concept very similar to
the dead state. This imply that:

    * We'll have two very similar but different concept that confuse the user.

    * I'm going to implement the "dead state" concept, then the weeks after
      implement the "obsolete" concept that kind of "obsolete" the "dead state

That why I would prefer to implement de "dead" concept as a marker that change
the way mercurial handle it instead of a state distinct that frozen, liquid and

Some philosophical thought about the way we are doing it in mercurial:

With the recent and comming addition to mercurial[1] we are getting closer of
what Git does. It's then important to keep what makes mercurial different from
git. Mercurial is not just "git in python with a funny storage format",
mercurial have fundamental different approach than git in it's user interface.
Mercurial use a simple approach to allow the user to manipulate a whole graph
of revision. As the usage of this graph become more complex and the user more
experienced, mercurial offer several **optional** tool and concept that may
help him to handle this graph.  As far as I understand it's ui, git enforce
several concept and abstraction that must be mastered before being able to
handle the graph.

In my eyes, the main strength of mercurial is that it's "as much complicated as
need to get the stuff I need". The first three states concepts fit well in the
vision as they can be independently enabled if the user need it. The dead
concept in the other hand is pretty entangled to the liquid one. The need for
"dead" changeset raise from the liquid one. Once stuff are liquid you need a
way to get rid of it. moreover you can't kill frozen changeset. This encourage
me to see them in a different way than liquid and private.

Pierre-Yves David

[1] (bookmark, liquid, hiding changesets, garbage collection) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <>

More information about the Mercurial-devel mailing list