Kristian Lunde

www.klunde.net

Merging code bases

without comments

Yesterday I had the “pleasure” of merging two code bases of the same application. The code bases had been developed in two different parts of the world, but shared a common foundation. I got access to a development version of the code base a few weeks ago, and the final delivery of the application was done late last week. No version control system was shared between myself and the contractor which made the merge a bit more cumbersome. Unfortunately I could not wait for the contractor to finish the development before I started to add features and bug fixes to the application; this eventually resulted in two separate versions of the code base.

I was aware that this merge would going to happen from the very start so some precautions were taken before I started my own branch of the source code.

1. I separated all new features out in separate directories and added symbolic links to these in the existing code base. This worked very well and we had no problem at all adding the new features to the final delivery.

2. I tried to be very careful and keep track of all the bug fixes and changes done to the original code.

Trouble

I realized that we would have trouble with the final merge not long after I received the first development version, it was cluttered with bugs and issues which made it impossible to even run it in my development version. To get the application up and running I had to make a bunch of changes to the code.

In addition to the initial bugs I soon realized that the front end of the application (read: html and css) was a complete mess. The site was not browser compliant, nothing validated and it was impossible to go through. These issues would not be resolved by the contractor and since the project was on the clock it needed resolving as quickly as possible. This ended up in a complete rebuild of the front end which modified 300+ files.

1st Attempt – Failure

1. Created a git branch of my development code
2. Added the final code from the contractor to the branch

This ended up in a complete mess, nothing working, a complete mess.

2nd Attempt – Success

When the final delivery from the contractor came through the two code bases was in completely different states, most of the bug fixes I had was still needed.

1. Created a git branch of my code base
3. Found the differences from the initial development version we got and the final delivery

  1. diff -qr dev final | grep -v -e 'DS_Store' -e 'Thumbs' | sort > changes.txt

Where dev is the directory of the untouched development version we got access to, and final is the directory of the final delivery. This resulted in a complete list (changes.txt) of files which differed between the two original versions. It also identified files that was obsolete in and new files that was added. An example of the content in the changes.txt can be seen below.

  1. Files dev/view/file-1.php and final/view/file-1.php differ
  2. Files dev/view/file-2.php and final/view/file-2.php differ
  3. Only in dev/css: css-1.css
  4. Only in dev/css: css-2.css
  5. Only in dev/css: css-3.css
  6. Only in final/css: css.css
  7. Only in final/: file-a.php

4. Once I had this overview I added all the new files from the final version into my git branch.
5. Updated all the files I knew had not been changed. I had a list of all the core files which had been changed.
6. I manually had to go through all the core files that had been changed and compare them with the files from the final delivery.
7. Remove all old files which only were present in the development delivery.
8. Manual comparison of all the front end files, updating and merging these files by hand. Diff can not be used here since the entire front end has changed, and it would only result in a complete difference, still there might have been changes that I needed to incorporate with the new front end.

I still have approx 150 front end files to compare, it is time consuming and frustrating labor, but it seems to be the only way to do it. I keep testing the application while doing the update and so far all of the changes and updates has been successful.

The positive flip of this is that I get a good overview of the code and understanding of the application when I have to go through much of the code from the final delivery.

I might not have chosen the best solution and I would love to hear your approach if you have done similar things or have an opinion about it.

Be Sociable, Share!

Written by Kristian Lunde

September 16th, 2009 at 7:22 am

Leave a Reply

Get Adobe Flash player