[PATCH 6 of 8] obsolete: exchange obsolete marker over pushkey

[Pierre-Yves David]

On Fri, Jun 08, 2012 at 02:25:59PM +0200, Patrick Mézard wrote:
> So yes, they are similar in the fact they represent DAGs. But revlog entries
> are node -> parents, while obsolete one are node -> replacements, so the
> relation is reversed. Maybe that is not the right way to do it, but it let
> you tell whether a node is extinct or replaced and by who, which seems to be
> the basic operation.

The revision graph stores -nodes- and edges information are stored into node
themself.

The obsolete graph stores -edges-. The information do not really have a
"direction then" as once you have the edge you can travel is both way.[1]

The information is used in three category of operation:


A) What are the set of obsolete changeset.

- This is necessary to know what changeset are:

    - obsolete in general so we can warn the user in several situation
    - extinct() --> ignored and hidden
    - unstabale to warn the user and search for changeset to be stabilized

- This only requires to read the "precursors" field of the marker. No DAG to
  build at all.

- This happen for most mercurial operation//invocation.

B) What does the obsolete DAG look like

- This is only necessary to detect error and resolve them.

- This concerns only a few mercurial operation.

- This do not need to read metadata

C) Who and When created the marker

- This is only needed when the user explicitly ask for audit information about
  obsolete marker.


So obsolete marker will be used 95% of the time for (A) 4% of the time for (B)
and 1% of the time for (C)


> Revlog entries can have only 2 parents, while a node may be replaced by N
> others. And you want to access these N others without having to
> decode/decompress data. Same thing with other metadata.

We could decide to limit the amount of parent to 'two' is it bring a
significant benefit.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120608/c4b59bd6/attachment.pgp>