8

Do you find it easier to keep a branch for each company that uses software you support/develop? Each company will want "customizations" and I am just trying to figure out the best way to handle those changes. A branch for each company makes sense in the short term but I could see how this could cause issues with upgrades when a new version is developed.

Is better to have a branch for each company or to setup customizations so that they are always merged to a main branch to minimize issues with future releases?

Improve this question
2
  • what VCS are you using, that will dictate the answer, with something like Git, branches are the obvious choice, with CVS well the obvious choice is move to Git :-)
    – user7519
    Feb 6, 2012 at 1:16
  • @Jarrod - I am using git.
    – Ominus
    Feb 6, 2012 at 15:56

4 Answers 4

Reset to default
18

Supporting a product that is customized for multiple customers is not a version control problem. It is a design and distribution problem.

Maintaining multiple code bases is a real pain. It's bad enough to need to duplicate the code base to support multiple platforms and languages, let alone multiple customers. Better instead to build a modular product. Sure, there will be elements that will require a larger degree of customization, and a small percentage of overlap where the code may need to be effectively duplicated, but it is better to create a very finely grained modular system design to cope, instead of attempting to branch where the risk is that the branches may become so divergent as to never be able to merge.

I myself work on an API that presently supports 3 hardware platforms, and greater than 3 customers. At the minimum, we would need to manage 9 separate code-bases if our code was not designed to be modular from the start. When I first arrived at the company nearly 10 years ago, the existing code base used conditional compiler directives to deal with 3 variants on a single platform, was about 50 times smaller than the present API incarnation, and took twice the effort to maintain. It took a lot of work, but we now have a product that never needs to be branched, and will be able to support literally any number of clients, platforms, and customizations.

So to specifically answer your question, It is better to maintain a single main branch provided you implement a design that will support a more modular development approach, and if your customization is required to be unavailable to more than a single customer, then you solve the problem in the way that your modules are accessed by your code, and in how they are deployed.

Improve this answer
4

While S.Robins is correct when he says this is a design and distribution problem not a version control problem, we have to be pragmatic. If you can't redesign your product (to use dependency injection for configuration for instance) then you might still be able to use your VCS to assist in managing the complexity your design introduces.

The big problem with using branches to maintain different versions of a product for different customers is managing the scope and side effects of merges.

If you only ever develop new features outside of the customer specific branch, and only ever make customer specific changes in the customer branch then you will be fine. New features can be pulled down from the feature branch and customer changes never need to be merged up.

The problems come when you try to add a new feature in a customer branch or fix a bug there and then pull those changes out of the customer branch. Then you have to be very careful not to pull customer specific changes along with them.

Having worked in such an environment before, and experienced the pain of untangling an ill-advised merge, I would now work in a different way if I needed to support this kind of environment again.

I would put all customer specific modifications into a patch queue, managed in a per customer repository separate from the main code repository (or repositories).

With Mercurial, I would suggest you look at Mercurial Queues, an extension which comes as standard with TortoiseHg (you just have to enable it). With git, then this answer to git equivalent to hg mq? has some excellent pointers for equivalent git functionality.

Improve this answer
2
  • +1 it's nice to be correct... even if not necessarily pragmatic! :-P You are right however, that you can't always redesign simply to make life easier. Branching is hard. If you've got a good system to manage it in place, all will go well, yet sooner or later you'll end up with a series of bottlenecks, because programmers are human and not always as careful as we'd like to be. If refactoring begins as soon as a branch/merge workflow bottleneck occurs - or before if obvious -, it can save a load of heartache later. Problem is, most people don't think about it till it's too late to fix.
    – S.Robins
    Feb 8, 2012 at 1:07
  • 1
    Thanks. I wouldn't say that branching is hard though. If changes will always flow both ways eventually it's easy (you are just using branches to manage when the changes flow). It's when you want some changes to only flow in one direction that it starts to become hard. In that case, you need to adjust your workflow to accommodate it, which is why you might need to write (or seek out) tools to help you.
    – Mark Booth
    Feb 8, 2012 at 15:53
3

The last thing you want is different versions of your source code for different clients. Keeping all those versions synchronized as you add features and fix bugs is going to be a huge pain, and the longer you operate that way, the more difficult it'll be to fix the problem.

A much better solution is to make you software configurable in all aspects that your clients want to customize, and the create separate configuration files for each client. You don't necessarily have to deliver the config files to the clients -- the configurations might be source files that get built into each version that you deliver to a client, if you do separate builds for each client. Eventually, though, as your client list grows, it'll probably be easier to build a single binary that you deliver to all clients along with customized config files.

Improve this answer
-1

Contrary to previous answers, authors of which live in ideal world, I have to say: Branches (with good VCS) is single way (not "easier": just because there are not harder way) to maintain customer's customisation.

Permanent merges from vanilla-branch to customs isn't easy time, but - it works

Improve this answer
3
  • Merges from the main-line into the customer branch is easy with a decent VCS. It's going the other way that's the real pain (i.e. taking the changes that should go into the main-line without taking the changes that should only be on the custom version).
    – Mark Booth
    Feb 6, 2012 at 16:43
  • 1
    @MarkBooth - I'm too lazy to write obvious things. For me - merge (per se) from any side to any side isn't a mentionable task, if developers have logical workflow and internal discipline
    – Lazy Badger
    Feb 6, 2012 at 23:53
  • 1
    @LazyBadger +1 for relevant user name. :)
    – Ominus
    Feb 8, 2012 at 14:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.