Current DVCS are great tool to forge a series of flawless changeset on your own.

**collaborate** on such work in progress.

When people forge new version of a changeset they create a new changeset and get

way old content are *removed* from repository.

Mercurial Approach: Strip

With current version of mercurial, every changesets that exist in your

repository are *visible* and *meaningful*. To get ride of old changeset you

rewrote mercurial remove them from the repository storage. with an operation

called *strip*. After the *strip* the repository looks like if the changeset

never existed.

remove changesets from **your repository only**. If strip exists in other

repositories it will show of again and again. This only cure for this is to

strip the offending changeset from all repository. And operation at best

impractical and in most case impossible!

As consequence, **you can not rewrite something once you exchange it with

others**. The old version will still exists along side the new one [#]_.

Finally, as the repository format is not optimized for deletion. stripping a

To sum up, the strip approach is very simple but does not handle interaction

with the outer world. Which is unfortunate for a *Distributed* VCS.

Git Approach: Overwrite Reference

branch** are *visible* and *meaningful*.

.. warning:: add a schema::

        C

        | B---<foo>

        |/

        |

        A

    Only B and A are visible.

is still painful.

Basic concept

.. figure:: ./figures/example-1-update.*

    *Updating* a changeset

    Create one obsolete marker: ``([A'] obsolete A)``

.. figure:: ./figures/example-2-split.*

    *Splitting* a changeset in multiple one

    Create one obsolete marker ``([B1, B2] obsolete B)]``

.. figure:: ./figures/example-3-merge.*

    *Merging* multiple changeset in a single one

    Create two obsolete markers ``([C] obsolete A), ([C] obsolete B)``

.. figure:: ./figures/example-4-reorder.*

    *Moving* changeset around

    Reordering those two changesets need two obsolete markers:

    ``([A'] obsolete A), ([B'] obsolete B)``

.. figure:: ./figures/example-5-delete.*

    *Removing* a changeset:

    One obselete marker ``([] obsolete B)``

To conclude, a single obsolete marker express a relation from **0..n** new

changesets to **1** old changeset.

Basic Usage

versioned files but applied to changeset:

    * **browse** the content of your obsolete commit,

    * **compare** newer and older version of a changeset,

    * **restore** content of previously obsolete changeset.

Finally, obsolete marker can be **exchanged between repositories**. You are able to

share the result on your history rewriting operation with other and **collaborate

on mutable part of the history**.

Conflicting history rewriting operation can be detected and **resolved** as easily

as conflicting changes on file.

resolved using available information.

obsolete changesets

.. figure:: ./figures/error-obsolete.*

    Rebasing `B` and `C` on `A` (as `B'`, `C'`)

    This rebase operation added two obsolete markers from new changesets to old

    history.

operation.

Unstable changesets

achieve this:

* Pull a changeset based of an old version of a changeset [#]_.

* Use a partial rewriting operation. For example amend on a changeset with

.. figure:: ./figures/error-unstable.*

    Amend `A` into `A'` leaving `B` behind.

    In this situation we can not consider `B` as *obsolete*.  But we have all

    necessary data to detect `B` as an *unstable* branch of the history because

    its parent `A` is *obsolete*. In addition, we have enough data to

    automatically resolve this instability: we know that the new version of `B`

    parent (`A`) is `A'`, We can deduce that we should rebase `B` on `A'` to get

    a stable history again.

Proper warning should be issued when part of the history become unstable. UI

will be able to use the obsolete marker to automatically suggest resolution to

the user of even carry them out for him.

* movement

* handling deletion

* handling split on multiple head

.. [#] For this to happen one needs to explicitly enable exchange of draft

The two part of the obsolete set

.. figure:: ./figures/error-extinct.*

    Amend `A` and `C` leaving `B` behind.

    In this example we have two *obsolete* changesets: `C` with no *unstable*

    children is *extinct*. `A` with *unstable* descendant (`B`) is *suspended*.

    `B` is *unstable* as before.

Because nothing outside the obsolete set default on *extinct* changesets, they

If people start to concurrently edit the same part of the history they will

.. figure:: ./figures/error-conflicting.*

A' and A'' that will keep the same parent than `A'` and `A''` with two obsolete

markers pointing to both `A` and `A'`

.. warning::  TODO: Add a schema of the resolution. (merge A' and A'' with A as

              ancestor and graft the result of A^)

Reliable history

do not change the fact that **you should only rewrite the mutable part of the

* Public changesets are excluded from the obsolete set (public changeset are

  never hidden or candidate to garbage collection)

* *newer* version of public changeset are said **latecomer** and highlighted as

  error case.

Solving such error is easy. Because we know what changeset a *latecomer* try to

rewrite, we can easily compute a smaller changeset containing only the change

from the old *public* to the new *latecomer*.

.. warning:: add a schema

Conclusion

history rewriting operations. It is a new type of relation between Mercurial

- Very fast history rewriting operations,

- clean final history,

.. list-table:: Comparison on solution [#]_

   :header-rows: 1

   * - Solution

     - Remove changeset locally

     - Works on any point of your history

     - Propagation

     - Collaboration

     - Speed

     - Access to older version

   * - Strip

     - `+`

     - `+`

     - \

     - \ 

     - \ 

     - `- -`

   * - Reference

     - `+`

     - \ 

     - `+`

     - \ 

     - `+`

     - `-`

   * - Obsolete

     - `+`

     - `+`

     - `++`

     - `++`

     - `+`

     - `+`

.. [#] To preserve good tradition in comparison table, an overwhelming advantage

       goes to the defended solution.