mutable-history / docs / unstability.rst

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.

Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.