Project Details: With the introduction of Multiversion module in Drupal 8, we have a very powerful content revision API that can handle branching and conflict DETECTION. But there is not yet a way to SOLVE revision conflicts.
Proposed Solution: We store a graph of all the updated revisions from an entity and find a base revision from this graph with which two entities can be compared. This process is based on 3-way merge algorithm. According to this algorithm, we shall compare two revisions of an entity with another revision or actual node to detect what has been modified in those revisions. If the new revisions has modified content over different lines, the updated content shall be merged in the new revision along with the unchanged data from previous revisions. This is why we compare two entities with a base entity, to find out which part has been modified in the new revisions. If both the new revisions has modified the same data, a merge conflict would occur and user would be allowed to solve the conflict in a 3-pane window. You can find more about the project and the approach in the 3rd week blog post at my blog.
Work we did last week: We are done with the simple merge resolver as well now. The task was to resolve merge conflicts in linear entities which drupal implements by default. The approach we took for this was to return the entity last created in the revision. This way, the entity which was created last would be returned as it is the latest entity. We have also written tests for it. The code for the library can be found on the github repository.
Work we did this week: The multiversion module stores the revision status and other data in form of trees. To detect and solve conflicts, we need to convert this data in graphs. This week, we have been working on writing code which could create a graph from a given array.
We wrote a recursive function to create an array to store all revision Ids from the array and then we created nodes from those revision IDs. Next we are working on a function which creates edges between these nodes. The code is pushed here in the getGraphTest.php file.
We are done with the code and testing it to make sure it’s returning the expected output. Once we are sure it’s returning the correct data, we can implement the code into the multiversion module.
Task for the next week: We will complete the tests, get the code implemented in the multiversion module to return graph from the tree and will also try to complete the complex LCA resolver code as much as possible. We need to complete the graph creating code first as it’d be used in all next steps i.e, to find LCA using relaxedws/lca Library and to resolve merge conflicts using relaxedws/merge library.