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

But they perform poorly when it comes to **sharing** some work in progress and

**collaborating** on such work in progress.

When people forge a new version of a changeset they actually create a

new changeset and get rid of the original changeset. Difficultis to

collaborate mostly came from the way old content is *removed* from

a repository.

With the current version of mercurial, every changeset that exists in

your repository is *visible* and *meaningful*. To delete old

(rewritten) changesets, mercurial removes them from the repository

storage with an operation called *strip*. After the *stripping*, the

repository looks like if the changeset never existed.

This approach is simple and effective except there is a very big

drawback: you can remove changesets from **your repository only**. If

a stripped changeset exists in another repository it touches, it will

show up again. This is because a shared changeset becomes

part of a shared global history. Stripping a changeset from all

repositories is at best impractical and in most case impossible!

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

However backups are created while stripping a changeset in most

cases. This allow restoration of an old changeset but the process is

painful.

Finally, as the repository format is not optimized for deletion,

stripping a changeset may be slow in some situation.

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

interaction with the outer world, which is very unfortunate for a

*Distributed* VCS.

.. [#] various workarounds exist but they are workarounds with their own flow.

The Git approach to repository structure is a bit more complex: there

can be any amount of unrelated changesets in a repository, and **only

changesets referenced by a git branch** are *visible* and

*meaningful*.

This ease the process of getting rid of old changesets. You can just

leave them in place and move the reference on the new one. You can

then propagate those changes by moving the git-branch on remote host,

the newer versions overwritting the older ones.

This approach goes a bit further but still have a major drawback:

Because you **overwrite** git-branch you have no conflit resolution. The last

to speak wins. This makes collaboration on multiple changesets difficult because

you can't merge concurent updates on a changeset.

Every overwrite is a forced operation where the operator says "Yes I

want this to replace that". On a higly distributed environment, a user may

end with conflicting references and with no proper way to choose.

Because of this way to visualize a repository, git-branches are a very

core part of git. This makes the user interface more complicated and

moving through history more constrained.

Finally, even if all older changesets still exist in the repository, accesing them

As none of these concepts were powerful enough to embrace the need to

safely share rewritten history we needed another one.

Every history rewriting operation stores the information that old rewritten

changesets has a newer version available in a set of changesets.

single version of your changeset displayed by the UI.

Second, because obsolete changeset contents are still **available**,

you can

    * **browse** the contents of your obsolete commits,

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

    * **restore** contents of previously obsolete changesets.

Finally, the obsolete marker can be **exchanged between

repositories**. You are able to share the result on your history

rewriting operations with other prople and **collaborate on the

mutable part of the history**.

Conflicting history rewriting operation can be detected and

**resolved** as easily as conflicting changes on a file.

Detecting and solving tricky situations

History rewriting can lead to complex situations. The obsolete marker

introduces a simple representation for this complex reality. But

people using complex workflows will one day or another have to face

the intrinsic complexity of some real-world situation.

This section describes possible situations, define precise sets of

changesets involved in such situations and explains how the error

cases can be automatically resolved using available information.

Obsolete changesets

With the current version of mercurial, this *obsolete* part is

stripped from the repository before the end of every rewritting

operation.

In most cases the obsolete set will be fully hidden to both the UI and

discovery, hence users do not have to care about them unless they want to

audit history rewriting operations.

While exploring the obsolete marker possibility a bit further you may

end up with *obsolete* changeset with *non-obsolete* children. There

are two common ways to achieve this:

Proper warnings should be issued when part of the history becomes

unstable. The UI will be able to use the obsolete marker to

automatically suggest a resolution to the user of even carry them out

for him.

The two parts of the obsolete set

The previous section shows that there could be two kinds of *obsolete*

changesets:

likely meet conflicting situations when a changeset have been rewritten in two

This kind of conflict is easy to detect with an obsolete marker

because an obsolete changeset can have more than one new version. It

may be seen as the multiple heads case. Mercurial warns you about this

on pull. It is resolved the same way by a merge of A' and A'' that

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

Allowing multiple new changesets to obsolete a single one allows to

distinguish a split changeset from an history rewriting conflict.

Special rules apply for obsolete marker pointing to public changeset:

* Public changesets are excluded from the obsolete set (public

  changesets are never hidden or candidate to garbage collection)

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

  an error case.

Solving such an error is easy. Because we know what changeset a

*latecomer* tries to rewrite, we can easily compute a smaller

changeset containing only the change from the old *public* to the new

*latecomer*.

Obsolete marker is a powerful concept that allows mercurial to safely handle