Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

1. Denial: It’s never going to work (in a timely manner).
2. Anger: Why do I have to do the merge?
3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.