Why do developers get so freaked out about merging?  Could it be they lost their last job when their company merged with another company that outsourced all software work overseas?  Maybe the lane they were driving in on the way to work had to merge with another lane due to construction and they arrived an hour late.  These merge scenarios are certainly a good reason to loathe the mention of the word, but developers have far different reasons for avoiding file merges.  Developers spend long hours writing software code, and they are simply afraid that a merge will break it.  It's important for them to understand that if they have a good merge tool and know how to use it, they have nothing to worry about.

What is merging files anyway?  A common software version control tool feature allows you to branch file versions.  This is a way of allowing multiple users to work on the same file at the same time.  Two file versions share the same parent file (i.e., they were both checked out from the same version), and the changes of these two files are tracked individually by the version control tool on separate named "branches" of development.  At some point in time, the changes to these files can be brought back together on the same branch in the same file version.  In an attempt to simplify the process of merging, many merge tools automate the merge process, and this is what scares many users.  If they don't understand exactly how the automatic merge takes place, they are afraid that changes will be made that will break their code, and who wants to spend time fixing something that was already working?

The first bit of good news is that most version control tools allow you to perform merges on files in a checked out state.  Since the results of the merge are checked out, they have not been committed to the code database and the developer can run tests with the code in this "draft" state.  If the testing shows that there is something wrong that could have been caused by the merge and the user wants to start over, they can always undo their checkouts and start the merge process again from scratch.  If the result of the merge gets checked in and then problems are found, the pre-merge version can always be recovered or used as a point of comparison.  Hey, it's a version control tool!  That's what they're for!  Once the user understands this, they feel much better.

An automatic merge occurs when the tool finds "non-conflicting" changes that have occurred in the two file versions and automatically merges them.  For example, if a new line of code was added to one of the file versions, it will automatically be merged to the resulting file version.  Most merge tools observe changes on a line-by-line basis.  Automatic merges will not attempt to resolve "conflicting" merges that usually occurs when the text on a single line has changed from the parent version in both of the versions that are being merged.  For example, a line might define a value such as "number=1" in the parent version.  In one branched version, the line changes to "number=2", and in the other branched version the line changes to "number=3".  How can the tool automatically decide which line to choose?  It can't, so it leaves this up to the user to decide.

To help our users understand the logic of automatic merges, I used the following table that attempts to cover every possible merge situation and the result.  This table models the tool we were using and might not be true for every merge tool, but it is an illustration that you could modify to reflect how your own tool works.  To simplify this example, a line of code is assumed to be just a single character--a capital letter.  Contributor 1 and Contributor 2 represent versions of the file that were checked out from the same version (the parent) and modified simultaneously.  The term "inserted," means the line was inserted, and the term "added" means the line was added to the end of the file.

Even after automatic merge has completed, the decisions made by the merge can be seen by the user they have the ability to undo or change any of the choices made by the tool.  They also have the ability to turn off the automatic merge altogether before they do the merge.  This method can be used by the most skeptic users.  After they start to understand the merge process and how many changes could be done automatically, they should see the value in the automatic merge process.

To really help the users understand merging, it is best to create a test database and let the users run tests on their own.  Create a simple software project or even use simple text files that contain a minimum amount of information so the users can really see how things get merged.  Once they understand it, they never again run away screaming when it's time to do a merge.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment