Merging and conflicts

Merging is a real challenge for all product and service organizations that develop source code and other managed artifacts. In my previous post I introduced the notion of merging and began an exploration around some of the issues of merging. In this post I will talk about the conflicts that inevitably occur when merging two branches of the same artifact back into a single line, and locking mechanisms to help make that task a bit easier. These considerations apply to both source code and other managed artifacts like requirements, but there are differences which I will also explore.

In a typical SCM (source code management) system a software developer – let’s call her Alice – can “check out” a file from the repository, which takes a snapshot of the requested version of the file and drops it onto her local hard drive. Then Alice makes changes to the file and can “check in” the file back into the repository. If Alice is the only person working on the file, no problem. But if between the time Alice checks out the file and checks it back in, another developer – let’s call him Bob – has checked in his own modifications. The picture looks like this:

In this diagram I denote work done on a workspace as a PC symbol with a wavy line. The work might have also been done in a parallel development branch. It turns out that many of the issues are the same regardless of where the changes are being made, the only difference being that workspace changes are merged in from somebody’s PC and development branch changes are merged in from the server. But there are some differences, which I will show later.

In this diagram, Bob’s change was not so big, or it was easier, or he didn’t have to talk to people about to make his change. Whatever the reason, both he and Alice got the same original (version 18) but he checked his change in to the development line before Alice. Now Alice has to deal with the fact that her changes may be inconsistent with Bob’s changes. How might they be inconsistent? There are two main situations:

1. A source file consists of a series of lines of code, sometimes just a handful, sometimes many thousands. It could be that one or more of Bob’s changes occurred on exactly the same line as one of Alice’s changes.
2. The resulting changes were semantically different – they were working at cross purposes. For instance, Bob could have fixed a defect by instituting an adequate but inelegant workaround, while Alice could have fixed the same defect by doing a complete refactoring of the code.

Of course, the latter situation is much more difficult to remedy – in fact, if Bob and Alice work in the same development organization then the inconsistency should have been noticed well before they started their work. The process artifacts that designate the work to be done should clearly indicate which problems they are supposed to solve, and a change review board should have noticed that two solutions were proposed for the same problem, and the change review board should have rejected one of them. But let’s not get too far ahead of ourselves here… The point is, it could happen, and when it does it’s ugly and one of the parties involved is going to get annoyed.

Anyway, the first situation (direct line-by-line conflict) is much more common, but fortunately Alice is a developer who knows the code and can very likely figure out what to do to resolve the conflict. Note there isn’t much difference whether the artifacts are source code or property files, or XML files, or CSV (comma-separated value) files, or any other file-based artifacts where the lines tend to be relatively short and there tend to be quite a few of them. But if the artifact is a requirement or a documentation snippet, or a test case description, then the probability of conflict tends to increase either because the line length is longer or because there simply aren’t that many words in the artifact.

Even worse than text-based artifacts are binary files such as pre-2003 Word documents, or CAD drawings, or media files. For these files there is no merge capability at all. The development line must contain either one version or the other, and that’s it.

Conflicts do slow you down, so you want to avoid them. You have to think about what the other person did, and why they did it, and whether your changes are consistent with the other changes. Sometimes when merging source code, you get no conflicts at all and yet when you try to compile the files you get a compilation error. This could happen when, for instance, your changes include a call to a method that somebody else has deleted in the meantime. You get no such guidance when merging requirements, however – there is no compiler that understands the words inside your requirements and ensures that all requirements are self-consistent. Fortunately, the way business analysts work is they tend to “own” chunks of requirements for a while, and during that time no other users are likely going to make changes. The system can also be set up to explicitly prevent other users from making changes to an artifact that somebody has checked out – this is called locking. We’ll talk more about that later.

When merging changes from one development line to another, the problem is more difficult for two reasons:

1. Development lines tend to have many changes, so there are many more potential conflicts. Unfortunately, the person doing the merge must keep track of all the various reasons why all the various changes are being merged in. It’s hard enough to keep track of 3 things in your head at one time – try keeping track of a hundred! It’s impossible, which means you need tool support. And, as I’ve stated before, this requires a combination of access to process information (defect reports, feature requests and change orders) plus a good user interface. We’re making good progress on the first requirement, but the user interface is a problem currently.
2. The person doing the merge is often not the person who made the changes. Even if it were a developer, often a whole team contributes to a development line so he or she would be only one member of the team. Often the situation is even worse – the person doing the merge is a configuration specialist, or “build master”, who may understand software development but is not immersed in it each day, nor privy to all the project goals and requirements.

Regardless of whether you are merging changes from a developer’s workstation into the development line, or merging from a side-branch into the development line, you need good tools and ready access to process information to do it efficiently.