StatesPlan - a draft of the sprint discussion about liquid hg

[Pierre-Yves David]

On Sat, May 07, 2011 at 03:06:53PM -0500, Matt Mackall wrote:
> I've written this up in a form I hope gives a pretty clear plan for the
> groundwork here:
> 
> http://mercurial.selenic.com/wiki/StatesPlan
> 
> This also proposes some UI for this feature (the hg state command and
> the state: field in the log), which we'd been mostly handwaving to this
> point.

There is a sentence I'm not sure to understand (and not sure to agree with one
of the interpretation)

>> If a client has a dead changeset and happens to pull a remote changeset that
>> is an ancestor of it, the changeset is becomes liquid or frozen as
>> appropriate.

We are talking about the case where, A changeset `A` is the death set. A
changeset `B` is children of `B` not in the death set.

Do you mean:

    (1) `A` is removed from death set ?

    (2) `A` is kept in the death set but treated as it's children (liquid/local).

I prefer the (2) options because:

    It is more accurate, and the more data we have the more stuff we can get
    right.  specific extension may be done to highlight such case.

    It prevent unexpected reviving of death changeset:
    * I pull `A` from intern-babar I dedice it's worthless `hg state --dead A`
    * I pull `B` from intern-babar I dedice it's worthless `hg state --dead B`
    I don't expect pulling `B` to revive `A` and force me to explicitly kill `A` again.

    It ensure propagation of dead changeset. if you don't push the non-dead
    children, you better keep killing the dead changeset.

    This behaviour fit well with the one we are going to want for the obsolete
    stuff (left out of the document).

> I've mostly left out Pierre-Yves very interesting model for changeset
> management (briefly discussed at the end) as it would double the length
> of the document to go into a similar level of detail and states need to
> be implemented first at any rate.

I think we can get an implementation of "dead" compatible with the lower level
of my model.  As we discuted during the sprint, the  stuff can be obsolete
express with a set of "{1,2} to 1" relations.


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.

It make sense because:

    * changeset that evolved into another have about the same behaviour that dead one,

    * I think it's better to have fewer mecanisme to exchange data. (simpler to
      understand, easier to maintains),

    * The early compatible mecanism is introduce the more version we'll be
      compatible to,

    * obsolete is only "addionnal data about why the changeset is dead". they
      can be handle as "dead" by client without obsolete logic.

Moreover, I don't really care to have core UI to handle obsolete stuff. It's
important to have a minimum handling of this data in core (as describe above),
but I believe it 's wiser to keep experimentation related to obsolete into
extension for some time. When we get a nice UI that handle all case and works
well we can "freeze" by mooving it into the code. Until that we better let
multiple approach be experimented into extension.  Parren and I had discussion
about what could be obsolete UI during the sprint.  Parren should write a sumup
soon.

-- 
Pierre-Yves David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110509/648b5986/attachment.pgp>