# HG changeset patch
# User Pierre-Yves.David@ens-lyon.org
# Date 1336747439 -7200
# Node ID 9d37254031fc94c565846021a4b4d7bb2cbd2131
# Parent  2f68c708e10b3959e7bdf369aba2c5f1b6045901
[doc] add Question and Answer about Obsolet Marker Implementation

diff -r 2f68c708e10b -r 9d37254031fc docs/obs-implementation.rst
--- a/docs/obs-implementation.rst	Fri May 11 11:52:15 2012 +0200
+++ b/docs/obs-implementation.rst	Fri May 11 16:43:59 2012 +0200
@@ -4,6 +4,78 @@
 -----------------------------------------------------
 .. warning:: This document is still in heavy work in progress
 
+Main questions about Obsolete Marker Implementation
+-----------------------------------------------------
+
+
+What data should be contained in a Marker ?
+````````````````````````````````````````````````````
+
+There is 2 data that **must** be stored
+
+: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 ?
+
+This is probably a good idea to have an unique Identifier, for UI, transfert and
+access.
+
+    :id: same as changeset but for marker.
+
+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)
+
+:date: date of the marker creation
+
+:user: ui.username
+
+To go further:
+
+:description: "Optional reason for the rewrite (generated of added by the user)"
+
+:tool: the automated too that made this
+
+:operation: Kind of rewritting operation that created the marker (delete,
+            update, split, fold, reordering) To help conflict resolution.
+
+Any other data ?
+
+Shall we store the marker alone or should be group them ?
+`````````````````````````````````````````````````````````````
+
+Several operation rewrite multiple changeset at once. It may make sense to group
+marker in this case.
+
+This could be seen as the same improvement than the introduction of coherent
+"changesets" in Files version control.
+
+This would help exchange and undo.
+
+
+How shall we store Marker on disk (and in memory) ?
+`````````````````````````````````````````````````````````
+
+We need to quickly load the 'object' to know the "obsolete" set.
+
+We need quick access by object and subject.
+
+How shall we exchange Marker over the Wire ?
+`````````````````````````````````````````````````````````
+
+We can have a lot of markers. We do not want to exchange data for the one we
+already know. Listkey() is not very appropriate there as you get everything.
+
+Moreover, we might want to only hear about Marker that impact changeset we are
+pulling.
+
+pushkey is not batchable yet (could be fixed)
+
+A dedicated discovery and exchange protocol seems mandatory here.
+
+
 Various technical details
 -----------------------------------------------------
 
@@ -12,7 +84,7 @@
 storing old changeset
 ``````````````````````
 
-The new general delta format allow a very efficient storage of two very similar
+The new general delta format allows a very efficient storage of two very similar
 changesets. Storing obsolete childrens using general delta takes no more place
 than storing the obsolete diff. Reverted file will even we reused. The whole
 operation will take much less space the strip backup.