Changes between Version 1 and Version 2 of PRO_CHANGE_MERGING_R0

Timestamp:

01/26/09 17:36:20 (16 years ago)

Author:

gogov

Comment:

--

PRO_CHANGE_MERGING_R0

@@ -4 +4 @@
 
 = Analysis =
-^(Give as much as possible of the needed information for designing and implementing the task in the following sections.)^
-
 == Overview ==
-^(Provide a brief overview of the whole task in its first revision. Stick to the current revision of the task, but keep an eye to the whole task progress, and stay alert for possible smells.)^
+The goal of this task is to create a concept on how to deal with online collaboration when multiple users are working on the same thing and some sort of merging their work needs to be done. [[BR]]
+In Sophie 2's context, the problems which occur should be described in terms of Changes and ProLib primitives.
 
 == Task requirements ==
-^(List the necessary requirements that the task must fulfill.)^
+ * Describe a simplified version of the general situation with online collaboration:
+  * there's a server
+  * there are two users of connected to this server who are working on a shared resource
+  * the server holds a log of changes up to some point of time (a ''synchropoint'') and the two users are synchronized up to this point
+  * each user performs his own set of changes
+  * both users upload their set of changes to the server so there's a conflict
+
+ * Some of the problems that arise are:
+  * how to express each user's changeset in terms of Changes and ProLib primitives
+  * how to implement merging:
+   * in what order to merge the subchanges of the two users' changesets
+   * how to handle operations from the different changesets which lead to invalid sequence of changes (for instance, one user inserts something in a frame, and the other user has already deleted the frame)
+  * how to implement it efficiently
+  * what if each user has a view on a model shared on the server and changes affecting this model are merged
+   * in what extent are the two views updated?
+   * some text, for instance, could be merged
+   * the text cursor position shouldn't be changed though, because if you exploit this approach for everything, at the end you are left with multiple users sharing the same view
+   * propose an idea how to solve this problem
+
+ * Provide ideas for solutions for the above problems
+
+ * Provide rough implementation of merging
 
 == Task result ==
-^(List the end product of the task (for example "Source code", "Wiki page", etc.))^
+ * New code that meets the above requirements
+ * Add appropriate tests for the code
+ * Proposals for solutions to the described problems
+ * Graphic explanation of the general synchronization problem described above
 
 == Implementation idea ==
-^(Provide some rough implementation idea(s).)^
+ * For the graphics, provide a graphic of both users' changesets and the log of changes on the server, viewed as lists of Changes/primitives
+ * Think of different schemes how to solve the merging problem:
+  * first the entire changeset of the first user is uploaded and then the changeset of the second user
+  * the two changesets are merged by sorting all incoming changes by the time of their actual occurrence
+  * propose other if you have any ideas
 
 == Related ==
-^(Add links to related tasks that could be useful or helpful.)^
+[wiki:PRO_CHANGE_PRIMITIVES_R0] [[BR]]
+[wiki:PRO_CHANGE_UNDO_MANAGER_R0] [[BR]]
+[wiki:PRO_CHANGE_TRANSACTION_SAFETY_R0] [[BR]]
+[wiki:PRO_CHANGE_COMPOSING_R0] [[BR]]
+[wiki:PRO_CHANGE_MANAGER_R0] [[BR]]
 
 == How to demo ==
-^(Provide instructions for demonstration of the task.)^
+ * Show the new code
+ * Run the tests
+ * Show the explanation graphics for the general problem
+ * Explain shortly the problems and discuss the proposed solutions
 
 = Design =