Creating the "Conflict" module - week5, GSoC16

Submitted by rakesh on Wed, 06/29/2016 - 22:09

After finishing our work with the PHP libraries to find Lowest Common Ancestor from a graph and then to merge the changes from updated entites, we finally moved to the next step of the project i.e, Making these libraries work with Drupal system.

For those who are not familiar with the project, I would strongly recommend to go through my 3rd week blogpost of GSoC16 where I have given a complete and detailed description of the project.

Coming back to where we started, to make these libraries work with Drupal, we have started work on creating a D8 module "Conflict" which would take care of merging and conflicts.

I spent this week studying about dependency injection, developing pluggable services and other Drupal development stuff rather than starting with the implementation right now. The goal is to keep the module pluggable and to not to depend on Multiversion or Replication module. The initial stab at Conflict module for Drupal 8 will only do a few simple things:

  1. Implement two different ancestor resolvers: 

Since the LCA resolution is pluggable inside, we shall provide two different implementations for this:

  • A simple resolver which find the LCA for revisions that use the default linear revision system provided by core. This resolver will work with any Drupal 8 site.
  • A more complicated resolver that uses the relaxedws/lca library and RevisionTreeIndex from Multiversion module. This step depends on #2748403: Add getGraph() to RevisionTreeIndex . This resolver will only work with sites that uses Multiversion module.
  1. Implement two conflict resolvers: 
  • A simple resolver that just returns the revision with the largest revision ID. This resolver will work with any Drupal 8 site.
  • A more complex resolver that uses the Serialization module to normalize the given revisions into arrays and then use the relaxedws/merge library to perform the merge. This resolver will only work with sites that uses Multiversion module.

We set up an issue to track the progress of this project and the code will be pushed to the drupal-conflict public repository over github. It has the d7 code for it already and now we are creating the code for d8 over "dev-8.x" branch.

Note that the main focus is to make the services pluggable so that those users who don't use Multiversion module can also use this module. Also, there might be developers who might want to use some other approach to find LCA or solve conflicts, they can also add their own services easily if we make the module services pluggable.

To understand the use of services, I went through Services and dependency injection in Drupal 8 and the article about Service Tags over After going through these articles, I could easily see the clear picture of the approach my mentors told me about. 

We will be starting by implemeting a method to find Lowest common ancestor which would work with linear entities and would not require Multiversion module. It'd work with some predefined approached like the last entity updated. We'd be deciding about which approach would be best for this as there are many to use. Once we decide, we would start with the implementation. The best way would be to write the unit test and build the service until it passes the test. This is what we have decided this week. By the next week, we would start the implementation and probably would have done the LCA implementation with the module.