Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 16 Oct 2012 15:39:12 +0200] rev 17776
obsolete: flip `obstore.successors` and `obsolete.precursors`
People were confused by the fact `obstore.precursors` contained marker allowing
to find "precursors" and vice-versa.
This changeset changes their meaning to:
- precursors[x] -> set(markers on precursors edges of x)
- successors[x] -> set(markers on successors edges of x)
Some documentation is added to clarify the situation.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 14 Oct 2012 23:33:10 +0200] rev 17775
obsolete: add example of marker usage in the documentation
Recent discussion with Augie Fackler pointed the lack of such example in the
documentation.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 15 Oct 2012 00:12:06 +0200] rev 17774
obsolete: cheap detection of nullid as successors
Nullid as successors create multiple issues:
- Nullid revnum is -1, confusing algorithm that use revnum unless you add
special handling in all of them.
- Nullid confuses "divergent" changeset detection and resolution. As you can't
add any successors to Nullid without being in even more troubles
Fortunately, there is no good reason to use nullid as a successor. The only
sensible meaning of "succeed by nullid" is "dropped" and this meaning is already
covered by obsolescence marker with empty successors set.
However, letting some nullid successors to slip in may cause terrible damage in
such algorithm difficult to debug. So I prefer to perform and clear detection of
of such pathological changeset. We could be much smarter by cleaning up nullid
successors on the fly but it would be much for expensive. As core Mercurial does
not create any such changeset, I think it is fine to just abort when suspicious
situation is detected.
Earlier experimental version created such changesets, so there are some out
there. The evolve extension added the necessary logic to clean up its mess.