.. Copyright 2011 Pierre-Yves David <pierre-yves.david@ens-lyon.org>

..                Logilab SA        <contact@logilab.fr>

-----------------------------------

The instability Principle

-----------------------------------

An intrinsic contradiction

-----------------------------------

XXX starts by talking about getting ride of changeset.

    * History is organized as a robust DAG,

    * History can be rewritten.

However, the two concepts are in contradiction:

To achieve a robust history, three key elements are gathered in *changesets*:

    * Full snapshot of the versioned content,

    * Reference to the previous full snapshot used to build the new one,

(with various other metadata). This identification is a key part of DVCS design.

changeset, which is semantically good.

.. figure:: ./figures/edit-is-rewrite-step2.svg

To avoid duplication, the older changeset is usually discarded from accessible

history. I'm calling them *obsolete* changesets.

::

  Schema base,  A and A' and B.

I'm calling these children **unstable** because they are based on a

This instability is an **unavoidable consequence** of the strict dependency of

Everybody is working around the issue

------------------------------------------------

Rewriting all at once

``````````````````````````

The simplest way to avoid instability is to ensure rewriting

operations always end in a stable situation. This is achieved by

rewriting all affected changesets at the same time.

Rewriting all descendants at the same time when rewriting a changeset.

::

  Schema!

Several Mercurial commands apply it: rebase, collapse, histedit.

there is no way to be sure it does not have descendants somewhere else.

Therefore **if you rewrite changeset that exists elsewhere, you can't eradicate

the risk of instability.**

```````````````````````````````````

To work around the issue above, Mercurial introduced phases, which

prevent you from rewriting shared changesets and ensure others can't

pull certain changesets from you. But this is a very frustrating

limitation that prevents you to efficiently sharing, reviewing and

collaborating on mutable changesets.

In the Git world, they use another approach to prevent instability. By

a named branch. But once again this is a huge blocker for

collaborating. Moreover clueless people **will** mess up social

convention soon or later.

````````````````````````````

The other approach in Mercurial is to keep the mutable part of the

history outside the DVCS constraint. This is the MQ approach of

sticking a quilt queue over Mercurial.

This allow much more flexible workflow but two major feature are lost in the

process:

                 becomes very painful when context changes.

Ignore conflicts

```````````````````````````````````

Another ignored issue is a conflicting rewrite of the same changeset.

If a changeset is rewritten two times we have two newer versions,

and duplicated history is complicated to merge.

Mercurial work around by

The "One set of mutable changset == One developer" mantra is also a way to work

around conflicting rewriting of changeset. If two different people are able to

one, but it does not care about divergent version. It is the equivalent

of "common ftp" source management for changesets.

Facing The Danger Once And For All

------------------------------------------------

will never show up!

Obsolete marker can handle the job

```````````````````````````````````

instability and to stop working around the issue! This is why I

Obsolete markers have two key properties:

  By explicitly marking the obsolete part of the history, we will be able to

  easily detect instability situation.

* Relations between old and new version of changesets are tracked by obsolete

  markers.

       section dedicated to obsolete marker for details.

````````````````````````````````````````````````

This proposal should **first** be seen as a safety measure.

::

    $ hg pull

    added 3 changeset

    +2 unstable changeset

    (do you want "hg evolve" ?)

    working directory parent is obsolete!

    $ hg push

    outgoing unstable changesets

    (use "hg evolve" or force the push)

::

    $ hg up 42

    $ hg commit --amend

    changeset have descendant.

    $ hg commit --amend -f

    +5 unstable changeset

    $ hg rebase -D --rev 40::44

    rebasing already obsolete changeset 42:AAA will conflict with newer version 48:BBB

While allowing powerful feature

````````````````````````````````````````````````

* Help to automatically solve instability.

* "prune" changeset remotely.

* track resulting changeset when submitting patch//pull request.

* Focus on what you do:

  I do not like the "all at once" model of history rewriting. I'm comfortable

  with instability and obsolete marker offer all the tool to safely create and

  handle instability locally.