StatesPlan - a draft of the sprint discussion about liquid hg
Matt Mackall
mpm at selenic.com
Mon May 9 09:32:54 CDT 2011
On Mon, 2011-05-09 at 12:48 +0200, Pierre-Yves David wrote:
> 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.
That should read 'is a descendant'. It's nonsensical as written; it is
of course not possible to pull a new ancestor.
I've updated it to read:
"If a client has a dead changeset X and happens to pull a remote
changeset Y that is a descendant of it, changeset X becomes liquid or
frozen as appropriate. If Y is frozen, X must be frozen. If Y is liquid,
X is made liquid."
> 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.
I assume you meant child of 'A'.
> Do you mean:
>
> (1) `A` is removed from death set ?
Yes.
> (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 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 is a classic case of the "A modified, B deleted" merge conflict.
There are three ways to handle it:
a) conservative (revive the dead changeset automatically)
b) dangerous (kill its descendants automatically)
c) interactive prompting
I'm inclined to rule out option (b) entirely. And I'm not a fan of (c)
either.
> 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.
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.
For instance, a changeset can be simultaneously liquid and obsolete. Or
local and obsolete. But not simultaneously liquid and local. Further an
obsoleted changeset has an "obsoletor", and that obsoletor remains
relevant even if a new descendant of the obsoleted changeset shows up.
In other words, obsolete markers are a completely different animal and
not states at all.
Just a reminder: your changeset evolution concept is not the only goal
of this process. In fact, it is the farthest goalpost yet identified.
The game plan is to head in that direction, but to score points well
before we get there. We will want dead changesets long before we're in a
position to get obsolete markers right.
--
Mathematics is the supreme nostalgia of our time.
More information about the Mercurial-devel
mailing list