Error: Macro BackLinksMenu(None) failed

compressed data is corrupt

Error: Macro TicketQuery(summary=PRO_CHANGE_MERGING_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed

current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

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.
In Sophie 2's context, the problems which occur should be described in terms of Changes and ProLib primitives.

Task requirements

• 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

• 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

• 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

PRO_CHANGE_PRIMITIVES_R0
PRO_CHANGE_UNDO_MANAGER_R0
PRO_CHANGE_TRANSACTION_SAFETY_R0
PRO_CHANGE_COMPOSING_R0
PRO_CHANGE_MANAGER_R0

How to demo

• 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

^{(Describe your design here.)}

Implementation

^{(Describe and link the implementation results here (from the wiki or the repository).)}

Testing

^{(Place the testing results here.)}

Comments

^{(Write comments for this or later revisions here.)}