obsolete feature targeted for 2.3

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Jul 5 20:02:25 CDT 2012


Here is news from my effort to put obsolete into core:


Current targeted features
-----------------------------------------------------------------------------------

I'm trying to get the following obsolete related features into core before 2.3 freeze:

(1) Exclusion of obsolete changeset from exchange (pull/push/out/inc/bundle/etc)

    If obsolete markers are to replace strip in most situation:
    we need to stop propagating obsolete changeset.

(2) Obsolete marker exchange outside pushkey

    Exchanged using pushkey are doomed for data size reason.
    This "new" version will probably still send and receive everything all the time :-/

(3) Hiding obsolete changeset inside the UI

    If obsolete markers are to replace strip in most situation:
    We need to hide them from the user point of view.

Important but complicated stuff
-----------------------------------------------------------------------------------

The two elements below are very critical feature we need before having obsolete marker "mature". But we are too advance in the 2.3 cycle to tackle them now.

- Changelog level filtering

  We need to replace inefficient and local filtering by a proper generic filtering mecanism.
  secret phase could benefit from it too.

- Smart obsolete marker exchange

  a) We can't dump everything all the time, we need a way to send unknown marker only.
  b) We should push marker relevant to pushed/pulled set only. 

Smaller most wanted feature that I probably won't have time to push before freeze
-----------------------------------------------------------------------------------

- alter heads checking on push/pull and +/- heads reports
- detection of all problematic situation (unstable, latecomer, conflicting)
- create obsolete marker during rewrite operation (amend, rebase, histedit, mq)
- display relevant warning and obsolete related data in the UI
- Optimisation (the current code the highly inefficient for now)
- automatic resolution of all problematics situation (unstable, latecomer, conflicting)

Various
-----------------------------------------------------------------------------------

People should be able to experiment with obsolete markers with 2.3 but don't except creation of obsolete marker by default. Performance will probably be very poor too. Things should improves during the 2.4 cycle.

details on the concept still available here http://hg-lab.logilab.org/doc/mutable-history/html/

I'll make a new release of my experimental extension compatible with current mercurial core soon.

My current work are visible at http://hg-lab.logilab.org/wip/hg/graph/ea8a189541e7 as usual.

Of course, any help are welcome!

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list