Polyoperable

I was stuck in a strange situation today. Typically in software development, branches are used for “one offs” – such as a maintenance branch off of a major line of code.

My dilemma today was slightly different. I have an existing web site and I need to make a some-what duplicate of it for another site. Two different websites. They each will have the same base skeleton and functionality but their look and feels will be different. They will each be a living project and the same functionality will be given to both sites over time – even though we may not want to ever merge some of the changes to both branches.

cmReady has been using Mercurial as our CM tool of choice for the past year because it’s easy to use and we need to be able to take our entire histories to customer sites. In the past, creating a maintenance branch has been super easy. But can Mercurial handle this particular challenge?

The answer is yes. Am I completely satisfied with the solution(s)? My answer: “Eh. Mostly.”

Note: Before we being, I’d like to first revisit the cardinal rule of SCM branching: Always create a branch as late in the development process as possible. If I were only half-way through with building Site A, I’d try to hold off on creating Site B site as long as I could. The reason is clear: any change I make in either line will have to be merged into the other. Lots of changes on both sides? Lots of merges. What a drag. So let’s start with the premise that Site A is pretty much finished. There may be small maintenance changes to be made in the future, but the main functionality that was planned for this version is completed.

So now what? Before we create our new branch, we have a big decision to make. How are we going to handle the files that will permanently differ in both branches?

• Let’s say it’s only a few files that are different – what then? Perhaps the easiest way of handling this situation is to just maintain the second set of files in the same database. No need for branching!
• But what if I have a good portion of files that will need to differ? Say 100 or more? What then? The best option in that scenario would probably be to split the differing “theme” files out of the database completely using its Convert extension. Then I’d end up with three databases: the common code and two sets of differing “theme” code, one each for Site A and Site B. The upside is that future maintenance is painless and a big bonus is that creating a third site will be a breeze. The downside is that you need to know in advance what the differing code will be and, more importantly, you’ll have to rewrite much of the common code to allow for different entry points, parameters and scenarios. This is the most time consuming of our options but also the best option for future code stability.
• Finally, if you believe that the common code will change infrequently, you can avoid site merges and instead use the hg export and import commands to merge only certain transactions to the other branch. This last choice may seem the most expedient – especially if you’ll have many small differences in the common code – but it’s also the most error prone. Should another developer accidentally do a push and merge, you’d better know how to recover from it.

Did you decide on the first option? Then you’re set! Looking at option two or three? Then stay tuned. I’m going to cover how to implement the second two options in future articles.