Quick Obsolescence Status

[Angel Ezquerra]

On Sep 19, 2012 6:36 PM, "Pierre-Yves David" <pierre-yves.david at logilab.fr>
wrote:
>
> Hello everyone,
>
> here is a quick status of my progress regarding the
> obsolescence feature:
>
> Done since 2.3
> --------------
>
> - Useful set or revision related to the feature are properly cached (is
not
>   turn repo in slugg),
>
> - "hg commit --amend" can creates obsolescence marker,
>
> - "hg rebase" can creates obsolescence markers,
>
> - hg push takes obsolescence in account before warning about new heads,
>
> - bookmarks movement take obsolescence in account.
>
> - Proof of concept of changelog level filtering.
>
> Next Steps
> -------------
>
> - Changelog level filtering:
>
>   It is a critical piece of obsolescence implementation. I'll focus on it
so it
>   can land in core soon enough.
>
>   I've planned a voice Meeting with Matt tomorrow (2012-09-20) at 15:00
GMT
>   (17:00 in France 10:00 in Minneapolis). If you want to join use contact
me.
>   I'll send your details for a mumble server.
>
> - histedit compatibility:
>
>   Histedit is the last (sane) history rewriting tools shipped with core
without
>   obsolescence support. I'm planning to fix that "soon".
>
>   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?

Also, you seem to plan to have Mercurial 2.4 be the first mercurial version
with built in support for the obsolete concept.  What do you think would be
the minimum amount of changes necessary to add some usable obsolete
support to the next version of TortoiseHg as well?

Cheers,

Angel