[PATCH 6 of 7] context: add obsolete related function to changectx

[Pierre-Yves David]

On 23 mai 2012, at 23:12, Matt Mackall wrote:

> On Mon, 2012-05-14 at 18:10 +0200, Pierre-Yves David wrote:
>> # HG changeset patch
>> # User Pierre-Yves.David at ens-lyon.org
>> # Date 1337010174 -7200
>> # Node ID 24f1d1c09ad14226025c60a02b12a4cbf6908b8d
>> # Parent  83c2e502114062b05f25533ac172b40b95e686c1
>> context: add obsolete related function to changectx
>> 
>> ctx.obsolete(): return True if the changeset is obsoleted by any marker.
> 
> This one is redundant.

This methods run a simple inclusion check. Most of the obsolete marker usecase only care about this boolean.

The two methods bellows iterate over the content and create new python objects. This is much more costly

>> ctx.obsmarkers(): yield markerctx for marker making this changeset obsolete
> 
> If we have a'' -> a' -> a, does this return [a'', a'] or just [a'']? If
> the former, is that the interface that the average user of this will
> want?

This just return *obsolete marker* directly related to changeset.

  repo[a].obsmarkers() -> marker("a' -> a")
  repo[a'].obsmarkers() -> marker("a'' -> a'")

Average user don't care about this at all. They want:

    repo[a].newest() -> [(a,)]

See below for details

>> ctx.replmarkers(): yield markerctx for marker making this changeset a
>> remplacement
> 
> For both of these, we should lose "markers" and name them obsoleted()
> and replaced().

We need to be careful here, we have tons of various useful information to access regarding obsolete marker. We need a consistent naming there. But we may need to wait until we have a wider panel of user-code to freeze it:

Regarding obsolete markers themself
-------------------------------------

- obsolete marker using this changeset as "obsoleted"
- obsolete marker using this changeset as "replacement"

Maybe all obsolete-markers "related" to a changeset too.

Regarding other changesets
------------------------------------------

- obsolete-parents: changeset directly obsoleted by this of this one
- obsolete-children: changeset which are a direct replacement of this one
- obsolete-ancestors: all changesets replaced by this one (transitively)
- obsolete-descendants: all changesets which replace this one (transitively)

And the very important "newest version", element in obsolete-descendant not obsolete themself. (this is *not* a simple list. This is a list of "candidate-set" of newest version, eg:

  In simple case:

    a'' -> a' -> a

    repo[a].newest() -> [(a'',)]

  In split case:

    a1 --> a' -> a
    a2  /

    repo[a].newest() -> [(a'',a2)]

  In conflict case:

    a' --> a
    a''---/

    repo[a].newest() -> [(a',) (a'')]

All methods regarding changeset will probably need a "node" version which includes changesets unknown locally but referenced by marker.

Possible naming scheme
------------------------------------------

My initial idea was:

Stick for standard graph name with a prefix when applicable

- obsparents
- obschildren
- obsancestors
- obsdescendants


Add "node" for function returning node id (meh)

- obsparentsnode
- obschildrennode
- obsancestorsnode
- obsdescendantsnode

Add "marker" for function returning "obsolete marker" object

- obsmarkers
- replmarkers

Use some relevant name for other function

- newest
- obsolete -> bool

-- 
Pierre-Yves David