changeset 501:9a17c48c2099 stable

update implementation details

--- a/docs/obs-implementation.rst	Fri Aug 24 12:47:12 2012 +0200
+++ b/docs/obs-implementation.rst	Fri Aug 24 13:19:11 2012 +0200
@@ -8,100 +8,6 @@
 -----------------------------------------------------
 
 
-What data should be contained in a Marker ?
-````````````````````````````````````````````````````
-
-There are two critical pieces of information that **must** be stored
-in an obsolete Marker.
-
-:object:
-    the old obsoleted changeset
-
-:replacements:
-    list of new changeset. list size can be anything, including 0 (0..N)
-
-Everybody agreed on this point.
-
- ---
-
-This is probably a good idea to have an unique Identifier, for UI, transfer and
-access.
-
-    :id: same as changeset but for marker.
-
-The field below will depend on the way we exchange obsolete marker between
-changesets.
-
- ---
-
-Having audit data will be very useful. When it gets messy you need all the
-information available to understand the situation.
-
-I have the feeling that we are versioning history. Therefor we will probably
-need the same kind of information than when versioning Files.
-
-:date: date of the marker creation
-
-:user: ui.username
-
-To go further:
-
-:description: "Optional reason for the rewrite (generated by the user)"
-
-:tool: the automated tool that made this
-
-:operation: Kind of rewritting operation that created the marker (delete,
-            update, split, fold, reordering), to help conflict resolution.
-
-Matt said this is "too complicated". I'll wait for him to meet a very hairy
-situation to agree that they are needed.
-
-Leaving the door open to any addition data is an option too.
-
-How shall we store Marker on disk
-`````````````````````````````````````````````````````````
-
-Requirement
-.............
-
-We need to quickly load the 'object' to know the "obsolete" set.
-We need quick access by object and replacements to travels along the graph.
-
-Common Part
-.............
-
-The file is store in `.hg/store/obsmarkers`. It is a binary files:
-
-The files starts with a Format Version string
-
-
-Minimalistic proposal
-.........................
-
-The core of a Marker will we stored as:
-
-* number of replacement (8-Bytes integer)
-* node id of the obsolete changeset (20-Bytes hash)
-* node id of replacement changeset (20-Bytes hash x number of remplacement)
-
-Version with ID
-.........................
-
-This version add a node id computed from the marker content. It will be present
-*before* other data:
-
-* node id of the maker (20-Bytes hash)
-
-
-Version with Metadata proposal
-...............................
-
-An extra files is used to old metadata (date, user, etc) `.hg/store/obs-extra`:.
-
-The format of this field is undefined yet. This will add the following
-field at the end of a marker
-
-* offset of the metadata in obs-extra (8-Bytes integer)
 
 
 How shall we exchange Marker over the Wire ?
@@ -188,26 +94,11 @@
 Current status
 -----------------------------------------------------
 
-An experimental implementatione exists. What have been done so far.
-
-
-* 1-1 obsolete marker stored outside history,
+Obsolete marker are partialy in core.
 
-* compute obsolete-tip
-
-* obsolete marker exchange through pushkey,
-
-* compute obsolete, unstable, extinct and suspended set.
+2.3:
 
-* hidden extinct changesets for UI.
-
-* Use secret phase to remove from discovery obsolete and unstable changesets (to
-  be improved soon)
-
-* alter rebase to use obsolete markers instead of stripping.
-
-* Have an experimental mq-like extension to rewrite history (more on that later)
-
-* Have an extension to update and mq repository according evolution of
-  standard (more on that later)
-
+- storage over obsolete marker
+- exchange suing pushkey
+- extinct changeset are properly hidden
+- extinct changeset are excluded from exchange