# HG changeset patch
# User Pierre-Yves.David@ens-lyon.org
# Date 1336774338 -7200
# Node ID 1e8e32d3871c225e81e8515079241e8b8e92a6c2
# Parent  9ccf8492d5c512cac46e788410b3085cb138b952
doc: idea about OnDisk Storage

diff -r 9ccf8492d5c5 -r 1e8e32d3871c docs/obs-implementation.rst
--- a/docs/obs-implementation.rst	Fri May 11 23:13:14 2012 +0200
+++ b/docs/obs-implementation.rst	Sat May 12 00:12:18 2012 +0200
@@ -11,22 +11,33 @@
 What data should be contained in a Marker ?
 ````````````````````````````````````````````````````
 
-There is 2 data that **must** be stored
+There is two critical data that **must** be stored in an obsolete Marker.
 
 :object:
     the old obsoleted changeset
 
-:subjects:
-    list of new changeset. **must** accept 0, 1 or 2 element at least. Shall it
-    accept more than three ?
+: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, transfert and
 access.
 
     :id: same as changeset but for marker.
 
+The field below will depends of the way we exchange obsolete marker betwenn
+changeset.
+
+ ---
+
 Having audit data will be very usefull. When it get messy you need all the
-information you can to understand the situation. (could be a group level)
+information you can to understand the situation.
+
+I have the felling that we are versionning history. Therefor we will probably
+need the same kind of information than when versionning Files.
 
 :date: date of the marker creation
 
@@ -41,26 +52,55 @@
 :operation: Kind of rewritting operation that created the marker (delete,
             update, split, fold, reordering) To help conflict resolution.
 
-Any other data ?
+Matt see this a "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
+`````````````````````````````````````````````````````````
 
-Shall we store the marker alone or should be group them ?
-`````````````````````````````````````````````````````````````
+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:
 
-Several operation rewrite multiple changeset at once. It may make sense to group
-marker in this case.
+We probably need a Format Version Number somewhere
+
+I'll put it in `.hg/store/obsmarkers-version`
+
+Minimalistic proposal
+.........................
+
+The core of a Marker will we stored as:
 
-This could be seen as the same improvement than the introduction of coherent
-"changesets" in Files version control.
+* 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)
 
-This would help exchange and undo.
+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)
 
 
-How shall we store Marker on disk (and in memory) ?
-`````````````````````````````````````````````````````````
+Version with Metadata proposal
+...............................
 
-We need to quickly load the 'object' to know the "obsolete" set.
+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
 
-We need quick access by object and subject.
+* offset of the metadata in obs-extra (8-Bytes integer)
+
 
 How shall we exchange Marker over the Wire ?
 `````````````````````````````````````````````````````````