Recap: We need to detect and resolve merge conflicts in Drupal8 which might arise when two users try to push the same entities but modified at respective end to the server without pulling the latest changes. We are implementing a “conflict” module to help detecting conflicts otherwise merge. For a complete description of what the project is about, please review to the 3rd week’s blog where I have given a complete walk through of the project. We finished two libraries, one to find the Lowest common ancestor from a directed acyclic graph and the other one to use that LCA as a base to perform recursive 3-way Merge algorithm by comparing local, remote and base entity before mid term and now we’re creating a module which will use those libraries.
For the progress till now, please refer to the article from last week. All the work till last week has been written in that article.
Target for this week was to create a simple Lowest common ancestor in Drupal 8 as a service in “Conflict” module.
Working: Entities in Drupal store revisions in a linear graph, for example if a node “A” has been edited 4 times, a linear graph would be formed looking something like:
A → B → C → D → E
This simple LCA resolver would find the parent of last edited revisions. In this case, it’d find and return “C” for revisions “D” and “E” as they both (D & E) have been modified from “C” and hence, “C” is their common parent.
Although it looks to be a pretty simple feature but it was ironically very tough for me to implement this code. Not the actual implementation but the testing part. After creating two libraries, I was starting to think that the “Testing” part is not so difficult after all but it proved me wrong *pun*. I made some silly mistakes and was trying on my own to solve them because I didn’t want to bug my mentors with such small mistakes. Just opposite to what I was thinking, I had to ask my mentors after nearly spending 2 days on a single error. My mentor “Andrei Jechiu” hardly took 2 minutes to point me in the right direction and I was back on track.
One thing I noticed while creating the module is that you don’t really just create the module, you learn a lot more than what you need and this is what I believe is the best part of working with Drupal and Google summer of code. The graph of learning increases exponentially.
So after solving the error, when I thought it shouldn’t take much time, I was right where I started, on another error which wouldn’t let me through but I didn’t make the same mistake of being struck with that error, after trying for like half day, I again had to ask “Tim Millwood” (My mentor) and just like Andrei, not only he pointed me to where I was making mistake (Services.yml was not properly defined), he also taught me how actually service container works in a much simpler way than many of the articles I read.
All the code we created can be found in drupal-conflict repository over github. We are still working on the Tests and once we are sure that the code is passing the tests, we shall move to the next step of creating a simple merge resolver which would work for linear entities and merge the updates in them. I was expecting to get over with this task this week only but it took much longer than I was expecting but I will take it as long as I’m learning new things.
Other than this part of project, we had an awesome Open session this week to encourage students to start contributing to open source. Students from various organizations like Fossasia, Drupal, Mifos Initiative and KD were there. Not only we met really talented people, we also had a talk about their projects and their approach.