1 -------------------------

     1 -----------------------------------------------------------

     2 Obsolete Marker Concept

     2 Why Do We Need a New Concept

     3 -------------------------

     3 -----------------------------------------------------------

     4 

     4 

     5 

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

     6 Obsolete marker is a powerful concept that allow mercurial to safely handle

     6 But they perform poorly whe is comes to **share** work in progress and

     7 history rewriting operations. It is a new type of relation between Mercurial

     7 **collaborate** on such work in progress.

     8 changesets that track the result of history rewriting operations.

     8 

     9 

     9 When people forge new version of a changeset they create a new changeset and get

    10 This concept is simple to define and provides a very solid base to:

    10 ride of the original changeset. Difficultis to collaborate mostly came from the

    11 

    11 way old content are *removed* from repository.

    12 

    12 

    13 - Very fast history rewriting operations,

    13 Mercurial Approach: Strip

    14 

    14 -----------------------------------------------------

    15 - auditable and reversible history rewritting process,

    15 

    16 

    16 With current version of mercurial, every changesets that exist in your

    17 - clean final history,

    17 repository are *visible* and *meaningful*. To get ride of old changeset you

    18 

    18 rewrote mercurial remove them from the repository storage. with an operation

    19 - share and collaborate on mutable part of the history,

    19 called *strip*. After the *strip* the repository looks like if the changeset

    20 

    20 never existed.

    21 - gracefully handle history rewriting conflict,

    21 

    22 

    22 This approach is simple and effective but have a very big drawnback: You can

    23 - allows various history rewriting UI to collaborate with a underlying common API.

    23 remove changesets from **your repository only**. If strip exists in other

    24 repositories it will show of again and again. This only cure for this is to

    25 strip the offending changeset from all repository. And operation at best

    26 impractical and in most case impossible!

    27 

    28 

    29 As consequence, **you can not rewrite something once you exchange it with

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

    31 

    32 Moreover backup are create stripped changeset in most case. This allow

    33 restoration of old changeset but the process is painful.

    34 

    35 Finally, as the repository format is not optimized for deletion. stripping a

    36 changeset may be slow in some situation.

    37 

    38 

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

    40 with the outer world. Which is unfortunate for a *Distributed* VCS.

    41 

    42 .. [#] various work around exists but they are work around with their own flow.

    43 

    44 Git Approach: Overwrite Reference

    45 -----------------------------------------------------

    46 

    47 Git approach for repository is a bit more complex: They can be any amount of

    48 changeset can exist in a repository. but **only changesets referenced by a git

    49 branch** are *visible* and *meaningful*.

    50 

    51 

    52 .. warning:: add a schema::

    53 

    54         C

    55         | B---<foo>

    56         |/

    57         |

    58         A

    59 

    60     Only B and A are visible.

    61 

    62 This ease the process of getting ride of old changeset. You can just leave them

    63 in place and move the reference on the new one. You can then propagate those

    64 change by moving the git-branch on remote host, newer version overwritting the

    65 older one.

    66 

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

    68 

    69 

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

    71 to spoke win. This make collaboration on multiple changeset difficult because

    72 you can't merge concurent update on changeset.

    73 

    74 Every overwrite is forced operation where the operator say "Yes I want this to

    75 replace that. On higly distributed environment user may end with conflicting

    76 reference with and no proper way to choose.

    77 

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

    79 part of git. This make user interface more complicated and move through history

    80 more constrainted.

    81 

    82 Finally, even if all older changeset still exist in the repository acces to them

    83 is still painful.

    84 

    85 

    86 -----------------------------------------------------

    87 The Obsolete Marker Concept

    88 -----------------------------------------------------

    89 

    90 

    91 

    92 

    93 

    94 As None of the concept was powerful enough to embrace the need to safely rewrite

    95 history, easily share and collaborate on mutable history we needed another one.

    96 

    33 This simple rules allows to express any possible history rewriting operation:

   106 All basic history rewriting operation can create a appropriate obsolete marker.

    34 

    35