changeset 1414:4198e2fad6ba

evolve: add an help topic about evolution

The text is probably bad, but this have been laying around for quite sometime
(with Mercurial core in mind) lets move forward and add this to evolve.

--- a/hgext/evolve.py	Fri Jun 19 17:47:48 2015 -0700
+++ b/hgext/evolve.py	Sat Jun 20 02:04:37 2015 -0700
@@ -23,6 +23,42 @@
 testedwith = '3.3.3 3.4.1'
 buglink = 'http://bz.selenic.com/'
 
+
+evolutionhelptext = """
+Obsolescence markers make it possible to mark changesets that have been
+deleted or superset in a new version of the changeset.
+
+Unlike the previous way of handling such changes, by stripping the old
+changesets from the repository, obsolescence markers can be propagated
+between repositories. This allows for a safe and simple way of exchanging
+mutable history and altering it after the fact. Changeset phases are
+respected, such that only draft and secret changesets can be altered (see
+:hg:`hg phases` for details).
+
+Obsolescence is tracked using "obsolete markers", a piece of metadata
+tracking which changesets have been made obsolete, potential successors for
+a given changeset, the moment the changeset was marked as obsolete, and the
+user who performed the rewriting operation. The markers are stored
+separately from standard changeset data can be exchanged without any of the
+precursor changesets, preventing unnecessary exchange of obsolescence data.
+
+The complete set of obsolescence markers describes a history of changeset
+modifications that is orthogonal to the repository history of file
+modifications. This changeset history allows for detection and automatic
+resolution of edge cases arising from multiple users rewriting the same part
+of history concurrently.
+
+Current feature status
+======================
+
+This feature is still in development.  If you see this help, you have enable an
+extension that turned this feature on.
+
+Obsolescence markers will be exchanged between repositories that explicitly
+assert support for the obsolescence feature (this can currently only be done
+via an extension).""".strip()
+
+
 import sys, os
 import random
 from StringIO import StringIO
@@ -57,6 +93,7 @@
 from mercurial import error
 from mercurial import exchange
 from mercurial import extensions
+from mercurial import help
 from mercurial import httppeer
 from mercurial import hg
 from mercurial import lock as lockmod
@@ -3250,3 +3287,16 @@
     def newcap(repo, proto):
         return capabilities(oldcap, repo, proto)
     wireproto.commands['capabilities'] = (newcap, args)
+
+def _helploader():
+    return help.gettext(evolutionhelptext)
+
[e-mail]
+def _setuphelp(ui):
+    for entry in help.helptable:
+        if entry[0] == "evolution":
+            break
+    else:
+        help.helptable.append((["evolution"], _("Safely Rewriting History"),
+                      _helploader))
+        help.helptable.sort()

--- a/tests/test-evolve.t	Fri Jun 19 17:47:48 2015 -0700
+++ b/tests/test-evolve.t	Sat Jun 20 02:04:37 2015 -0700
@@ -41,6 +41,46 @@
   >   for i in $@; do mkcommit $i ; done
   > }
 
+Test the evolution test topic is installed
+
+  $ hg help evolution
+  Safely Rewriting History
+  """"""""""""""""""""""""
+  
+      Obsolescence markers make it possible to mark changesets that have been
+      deleted or superset in a new version of the changeset.
+  
+      Unlike the previous way of handling such changes, by stripping the old
+      changesets from the repository, obsolescence markers can be propagated
+      between repositories. This allows for a safe and simple way of exchanging
+      mutable history and altering it after the fact. Changeset phases are
+      respected, such that only draft and secret changesets can be altered (see
+      "hg hg phases" for details).
+  
+      Obsolescence is tracked using "obsolete markers", a piece of metadata
+      tracking which changesets have been made obsolete, potential successors
+      for a given changeset, the moment the changeset was marked as obsolete,
+      and the user who performed the rewriting operation. The markers are stored
+      separately from standard changeset data can be exchanged without any of
+      the precursor changesets, preventing unnecessary exchange of obsolescence
+      data.
+  
+      The complete set of obsolescence markers describes a history of changeset
+      modifications that is orthogonal to the repository history of file
+      modifications. This changeset history allows for detection and automatic
+      resolution of edge cases arising from multiple users rewriting the same
+      part of history concurrently.
+  
+      Current feature status
+      ======================
+  
+      This feature is still in development.  If you see this help, you have
+      enable an extension that turned this feature on.
+  
+      Obsolescence markers will be exchanged between repositories that
+      explicitly assert support for the obsolescence feature (this can currently
+      only be done via an extension).
+
 various init
 
   $ hg init local