annotate docs/unstability.rst @ 221:d43b72724b84

doc: unstability principle

-----------------------------------
The Unstability Principle
-----------------------------------



An intrinsic contradiction
-----------------------------------


DVCS bring two new major concepts to the Version Control Scene:

    * Organisation of the history with robust DAG,
    * Mutation of history.


However, the two concepts opposes them self:

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

    * Full snapshot of the versioned content,
    * Reference to the previous full snapshot used to build the new one,
    * A description of the change who lead from the old content to the new old.

All three elements are used generate a *unique* hash that identify the changeset
(with various other metadata). This identification is a key part of DVCS design.

::

  Schema base,  A, B and B'

The old changeset is usually discarded
t in DVCS history.


::

  Schema base,  A and A' and B.

Rewriting a changeset with children does not changes children parent! And
because children of the rewritten changeset still **depends** on the older
"dead" version of the changeset with can not get ride of this dead version.

This is a very useful property because Changing B parent means changing B
content too.  This require the creation of **another** changeset.

I'll qualify those children as **unstable** because they are based one a dead
changeset and prevent people to get ride of it.

This instability is an **unavoidable consequence** of the strict dependency of
changese.  History Rewriting history alway  need to take it in account and
provide a way to rewrite the descendant on the new changeset to avoid
coexistence of the old and new version of a rewritten changeset..


Everybody is working around the issue
------------------------------------------------

I'm not claiming that rewriting history is impossible. People are 



Rewriting all at once
``````````````````````````



stable situation to stable situation

Distributed means that you do not control what happen outside your repository:


* phase.
* overwrite.


Boiler Plate


Loose the DAG robustness
````````````````````````````

The other approach is

mq -- quilt

Conflict too much conflict

Linear


Deny a lot of option
````````````````````````````



[] rewrite

[] exchange

[] collaborate


Facing The Danger Once And For All
------------------------------------------------
The more effort you put to avoid instability, the more option you deny. And even
most restrictive work flow can't garantee that instability will never show up!

It is time to provide a full featured solution to deal with instability and to
stop working around the issue! This is why I developing a new feature for
mercurial called "Obsolete marker".


* Any changeset is we want to get ride of is **explicitly** marked as "obsolete"
  by history rewritting operation..

* Relations between old and new version of changesets are tracked by Obsolete
  markers.

By explicitly marking the obsolete part of the history, we will be able to
easily detect appearance of unstability. By Storing a meta-history of changeset
evolution we are able to easily resolve instability and edition conflict.




No instability is still a bad situation.
No instability is still a bad situation that should be avoided.