view docs/obs-implementation.rst @ 1106:6b0cf1b73693 stable

evolve: replace each obsolete sha1 in the description with its latest successor

Obsolete csets are hidden by default and don't get pushed to the parent repo.
In order to avoid broken references in commit messages, it makes sense to evolve
those references to the latest and greatest successor, as each cset containing
them is evolved.  Of course, stale references can still occur if a commit in
branch 'A' references something in branch 'B', and that something in 'B' is
evolved but 'A' isn't subsequently evolved.

This alleviates the user that is evolving a series of commits from having to

  1) recognize that there is a hash that needs updating in any one of the series
  2) look up the latest successor manually
  3) hg amend -e

The regular expression for matching and the logic for replacing are borrowed
from the convert extension [1].

It might be nice for the output to state the reason that the reference couldn't
be updated (it was pruned, split or diverged), but that may be excessive for
something only displayed in verbose mode.  (Maybe it should be a ui.status()
instead?)

[1] http://selenic.com/hg/rev/45562379ce4e

.. Copyright 2011 Pierre-Yves David <[e-mail]>
..                Logilab SA        <[e-mail]>

-----------------------------------------------------
Implementation of Obsolete Marker
-----------------------------------------------------
.. warning:: This document is still in heavy work in progress

Main questions about Obsolete Marker Implementation
-----------------------------------------------------




How shall we exchange Marker over the Wire ?
`````````````````````````````````````````````````````````

We can have a lot of markers. We do not want to exchange data for the one we
already know. Listkey() is not very appropriate there as you get everything.

Moreover, we might want to only hear about Marker that impact changeset we are
pulling.

pushkey is not batchable yet (could be fixed)

A dedicated discovery and exchange protocol seems mandatory here.


Various technical details
-----------------------------------------------------

Some stuff that worse to note. some may deserve their own section later.

storing old changeset
``````````````````````

The new general delta format allows a very efficient storage of two very similar
changesets. Storing obsolete children using general delta takes no more place
than storing the obsolete diff. Reverted file will even we reused. The whole
operation will take much less space the strip backup.


Abstraction from history rewriting UI
```````````````````````````````````````````

How Mercurial handles obsolete marker is independent from what decides
to create them and what actual operation solves the error case. Any of
the existing history rewriting UI (rebase, mq, histedit) can lay
obsolete markers and resolve situation created by others. To go
further, a hook system of obsolete marker creation would allow each
mechanism to collaborate with other though a standard and central
mechanism.


Obsolete marker storage
```````````````````````````

The Obsolete marker will most likely be stored outside standard
history. They are multiple reasons for this:

First, obsolete markers are really perpendicular to standard history
there is no strong reason to include it here other than convenience.

Second, storing obsolete marker inside standard history means:

* A changeset must be created every time an obsolete relation is added. Very
  inconvenient for delete operation.

* Obsolete marker must be forged at the creation of the new changeset. This
  is very inconvenient for split operation. And in general it becomes
  complicated to fix history afterward in particular when working with older
  clients.

Storing obsolete marker outside history have several pros:

* It eases Exchange of obsolete markers without unnecessary obsolete
  changeset contents.

* It allows tuning the actual storage and protocol exchange while maintaining
  compatibility with older clients through the wire (as we do the repository
  format).

* It eases the exchange of obsolete related information during
  discovery to exchange obsolete changeset relevant to conflict
  resolution. Exchanging such information deserves a dedicated
  protocol.

Persistent
```````````````````````

*Extinct* changeset and obsolete marker will most likely be garbage collected as
some point. However, archive server may decide to keep them forever in order to
keep a fully auditable history in its finest conception.


Current status
-----------------------------------------------------

Obsolete marker are partialy in core.

2.3:

- storage over obsolete marker
- exchange suing pushkey
- extinct changeset are properly hidden
- extinct changeset are excluded from exchange