• When using "edit-merge-commit" (sometimes called "optimistic locking"), it is possible for two developers to edit the same file at the same time.
• Even if we use "checkout-edit-checkin", we may allow multiple checkouts, resulting once again in the possibility of two developers editing the same file.
• When merging between branches, we may have a situation where the file has been modified in both branches.

In other words, this mess only happens when people are working in parallel.  If we serialize the efforts of our team by never branching and never allowing two people to work on a module at the same time, we can avoid ever facing the need to merge two versions of a file.

However, we want our developers to work concurrently.  Think of your team as a multithreaded piece of software, each developer running in its own thread.  The key to high performance in a multithreaded system is to maximize  concurrency.  Our goal is to never have a thread which is blocked on some other thread.

So we embrace concurrent development, but the threading metaphor continues to apply.  Multithreaded programming can sometimes be a little bit messy, and the same can be said of a multithreaded software team.  There is a certain amount of overhead involved in things like synchronization and context switching.  This overhead is inevitable.  If your team is allowing concurrent development to happen, it will periodically face a situation where two versions of a file need to be merged into one.

In rare cases, the situation can be properly resolved by simply choosing one version of the file over the other.  However, most of the time, we actually need to merge the two versions to create a new version. 

What do we do about it?
Let's carefully state the problem as follows:  We have two versions of a file, each of which was derived from the same common ancestor.  We sometimes call this common ancestor the "original" file.  Each of the other versions is merely the result of someone applying a set of changes to the original.  What we want to create is a new version of the file which is conceptually equivalent to starting with the original and applying both sets of changes.  We call this process "merging".

The difficulty of doing this merge varies greatly for different types of files.  How would we perform a merge of two Excel spreadsheets?  Two PNG images?  Two files which have digital signatures?  In the general case, the only way to merge two modified versions of a file is to have a very smart person carefully construct a new copy of the file which properly incorporates the correct elements from each of the other two.

However, in software and web development there is a special case which is very common.  As luck would have it, most source code files are plain text files with an average of less than 80 characters per line.  Merging files of this kind is vastly simpler than the general case.  Many SCM tools contain special features to assist with this sort of a merge.  In fact, in a majority of these cases, the two files can be automatically merged without requiring the manual effort of a developer.

An example
Let's call our two developers Jane and Joe.  Both of them have retrieved version 4 of the same file and both of them are working on making changes to it.

One of these developers will checkin before the other one.  Let's assume it is Jane who gets there first.  When Jane tries to checkin her changes, nothing unusual will happen.  The current version of the file is 4, and that was the version she had when she started making her changes.  In other words, version 4 was her baseline for these changes.  Since her baseline matches the current version, there is no merge necessary.  Her changes are checked in, and a version of the file is created in the repository.  After her checkin, the current version of the file is now 5.

The responsibility for merging is going to fall upon Joe.  When he tries to checkin his changes, the SCM tool will protest.  His baseline version is 4, but the current version in the repository is now 5.  If Joe is allowed to checkin his version of the file, the changes made by Jane in version 5 will be lost.  Therefore, Joe will not be allowed to checkin this file until he convinces the SCM tool that he has merged Jane's version 5 changes into his working copy of the file.

Vault reports this situation by setting the status on this file to be "Needs Merge", as shown in the screen dump below:

Best Practice: Keep the repository in sight

This example happens to involve the need to merge only a single checkin.  Since Joe's baseline is 4 and the current repository version  is 5, Joe is only 1 version out of date.  If the repository version were 25 instead of 5, then Joe would be 21 versions out of date instead of just 1, but the technique is the same.  No matter how old his baseline is, Joe still needs to retrieve the latest version and do a three-way merge.  However, the older his baseline, the more likely he is to encounter conflicts in the merge. 

Keep in touch with the repository.  Update your working folder as often as you can without interrupting your own work. Commit your work to the repository as often as you can without breaking the build. It isn't wise to let the distance between your working folder and the repository grow too large.

 
• Version 4 (the baseline from which he and Jane both started)  
• Version 5 (Jane's version)
   
• Joe's working file (containing his own changes)

 
• What happens if Jane changed some of the same lines that Joe changed, but in different ways?  
• What happens if Jane's changes are functionally incompatible with Joe's?  
• What happens if Jane made a change to a C# function which Joe has deleted?  
• What happens if Jane changed 80 percent of the lines in the file?
   
• What happens if Jane and Joe each changed 80 percent of the lines in the file, but each did so for entirely different reasons?  
• What happens if Jane's intent was not clear and she cannot be reached to ask questions?

 
• Attempt to automerge  
• Use a visual merge tool  
• Redo one set of changes by hand

Best Practice: Only use "automerge on get"

It is widely accepted that SCM tools should only attempt automerge on the "get" of a file. In other words, when Joe realizes that he must merge in the changes Jane made between version 4 and version 5, he will tell his SCM client application to "get" version 5 and attempt to automatically merge it into his working file.  CVS, Subversion and Vault all function in this manner.

Unfortunately, SourceSafe attempts to "automerge on checkin". This is just a really bad idea. When Joe tries to checkin his changes, SourceSafe attempts the automerge.  If it believes that it has succeeded, then his changes are checked in and version 6 was created.  However, it is possible that Joe never examined version 6, or even compiled it.  The repository now contains a file which has never existed in the working folder of any developer on earth.  Its contents have never been seen by human eyes, and it has never been run through a compiler.  Automerge is safe, but it's not  that safe.

It is much better to "automerge on get". This way, the developer can (and should) examine the file after the automerge has happened. This simple change makes it easier to trust automerge.  Instead of trying to do the developer's job, automerge simply becomes a tool which the developer can use to get his job done faster.

 
•  
     When we shipped version 2.0, we created a branch for maintenance of the 2.0 release.  This is the tree where we develop minor bug fix releases like 2.0.1.
   
•  
     Our "trunk" is the place where active development of the next major release is taking place.
   

 
•  
     In the 2.0 branch, we implemented a fix to prevent dictionary attacks on passwords.  We considered this a bug fix, since it is related to the security of our product.  In concept this change was simple.  We simply block login for any account which is seeing too many failed login attempts.  However, implementing this mini-feature required a surprising number of lines to be changed.
   
•  
     In the trunk, we added the ability for Vault to authenticate logins against Active Directory.
   

Best Practice: Give concurrent development a try

Many teams avoid all forms of concurrent development. Their entire team uses "checkout-edit-checkin" with exclusive locks, and they never branch.

For some small teams, this approach works just fine. However, the larger your team, the more frequently a developer becomes "blocked" by having to wait for someone else.

Modern source control systems are designed to make concurrent development easy. Give them a try.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment