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.
By last week, we had already implemented the `GetGraph()` function in Multiversion module. The tree of revision is passed to the function and a graph is returned containing vertices keyed with the revision ID. After multiple tests, we made sure that the getGraph() method was returning the correct output. After this, the next task was to implement the feature to find Lowest Common Ancestor of 2 nodes from the Graph returned by getGraph() method.
We’ve created a class ‘ComplexLcaResolver’ in the Multiversion module which uses relaxedws/lca to find the LCA. This feature of finding LCA from a tree of revisions will be available only in those sites which uses multiversion module. We have implemented the functionality and now we’re in test phase. For now, there are bugs in this implementation and we are working on them. My mentors Andrei Jechiu, Dick Olsson and Tim millwood have been a real support and source of motivation for me so far. Not only do they assist me with the implementation ideas but also teaches me a lot when I am making silly mistakes or don’t know about any feature of Drupal. All the code we’ve written can be found here.
Now I’ve been working with Automation Testing for quite sometime and the most important thing that I’ve learnt is no matter how confident you are about your code, it’d fail under certain circumstances. It matters the most when your code would be used by many people out there. So, it’s better to test your programme thoroughly before pushing it. It’s time consuming and sometimes you have no idea where and why the tests are failing. This is one of the best things GSoC and my mentors have taught me. Running one test at my end takes nearly 45-60 minutes which makes the development process a lot slower. We can not work on multiple parts of the project as we are in last stage and every next part uses the results from the previous part. For example: Merge Library uses results from LCA library to perform 3-way merge algorithm. Once you are done with testing, you are pretty sure that there will be very few bugs in the program which will be discovered when the code goes live.
This week, we’d be done with ComplexLcaResolver implementation after few bug fixes and more tests. After that, we shall start ComplexMergeResolver implementation which will use relaxedws/merge library which we created in the first phase of GSoC16. This class would be used to detect merge conflicts and to merge the updated entities. It would also use Serialization module to normalize the given revisions into arrays and then, we can loop over those array to find any merge conflicts or to find where an entity has been updated and we’ll merge those changes into the main branch.
Also, I’d like to announce that we’ve launched relaxedws/lca library on packagist.org and it is ready to be implemented into any project. It can be found here: https://packagist.org/packages/relaxedws/lca