changeset 221:d43b72724b84

doc: unstability principle

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/unstability.rst	Fri May 04 18:16:41 2012 +0200
@@ -0,0 +1,128 @@
+-----------------------------------
+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.