In any software engineering project, there is code. These days, most software engineering projects also involve many people. Sometimes, in spite of efforts towards orthogonality, more than one of these people must work on code in the same source file. This is a merge conflict.

Aside that, there is the simple matter of synchronizing the existence of code that one person creates that another does not have. Simpler to solve, but equally important to progress as the merge conflict.

Sometimes, we do not give sufficient information to the source control system to unambiguously resolve a merge. In Subversion, this is the conflicted state.

What do we do about the conflicted state?

We take steps to avert a conflicted state:

• Commit early; commit often.
• Try to work on different parts of the code. Different modules, different files, or even just different methods.
• Mock objects. This is one of the least-utilized but most powerful conflict-avoidance practices.

In spite of this, almost every team eventually experiences a merge conflict. Methods for dealing with this vary:

• Destroy one person’s code, usually the one with less lines.
• Hand-pick lines to include from the merge and mark resolve (this is remarkably rare)
• Revert.

Usually, merges conflicts are surprising because of when they happen. Usually, it is a late night or early morning where the last committer is nowhere in sight.

To keep that person from being helpless, source control systems allow a comment to be attached to each commit of files.

Opportunity Abound

By making your commit messages useful, you can do more than save that hapless conflicted soul. By writing good messages, you enhance intrateam communication. ALERT: SPOILERS AHEAD. The one command you need to be an effective coach or team member is…

svn log

Use it during standups to remember just what exactly it was that you did last team time four days ago. Understand why 17 lines of code are gone from a file. Understand that Page X’s improper rendering is a known bug.

Bonus

The real bonus of having a quality source control log is that you have a concrete answer to the invariable coach question, “How is everything going?” They might (hint hint hint hint) even get involved enough to read the logs themselves, perhaps (hint hint hint hint) using a tool such as trac.

I honestly believe that on a day-to-day basis, barring new client information, a tool like trac coupled with excellently-written log messages can eliminate the need for a verbal standup for the team and for the coach. That, of course, depends on the definition of “excellently-written” log messages, which I’ll cover in my next entry. In the mean time, feel free to tell me why I’m wrong. 🙂