MQ and obsolescence (was: Quick Obsolescence Status)
pierre-yves.david at ens-lyon.org
Sun Sep 23 17:36:34 CDT 2012
On 20 sept. 2012, at 11:47, Angel Ezquerra wrote:
> On Sep 19, 2012 6:36 PM, "Pierre-Yves David" <pierre-yves.david at logilab.fr>
>> I do not plan to work on MQ support this cycle as there is several complex
>> issue with MQ.
> What will happen if you modify a changeset that obsoletes another one using
> MQ? Will MQ ignore obsoleted changesets? Will MQ be able to "break" the
> obsolete relationships?
I've some troubles to understand your question.
Obsolescence markers are stored outside "history of changeset". So MQ altering changeset will not change existing obsolescence markers.
However, MQ is not obsolescence-ready yet:
(1) It does not ignore hidden changeset. This means that is very quickly complains about multiple children and are currently unusable alongside obsolescence.
This point is easy to fix and should mostly resolve himself with changelog level filtering
(2) It does not create obsolescence marker yet.
This is tricker part as several behavior of MQ differ from other operation. For example:
- a qpop + qpush cycle recreate the very same changeset than before (so we can't just obsolete qpoped changeset).
- But a qpop + qrefresh (of previous patch) + qpush create a new changeset that replace the previouly pushed one (so we need to create an obsolescence relation)
We may eventually comes with a "sane" schema for MQ obsolescence compatibility but this is far from trivial.
**Working on MQ compatibility is not in my priority list**.
The evolve extension provide a similar experience with less pain. I prefer to focus on other core tasks right now.
Anyway, if someone want to work on making MQ compatible with obsolescence, I'll provide guidance and review.
More information about the Mercurial-devel