Source Control: Supporting multiple versions of a software

Question

The source control that my .NET WPF project uses is TFS. The customers for the project are all internal to the company. In near future we are going to release one version to only one customer because of a set of special requirements.

So we plan to create another branch in TFS and incorporate these requirements. The problem is that the customer may demand long term support for this version and may only want defect fixes to go into the product and not any new features that we incorporate on the main branch.

Though this is quite manageable currently, my fear is that 1-2 years down the line, we may end up having multiple source code branches which will create a maintainability headache of supporting n number of versions.

Could you please suggest ways to keep this entire situation manageable, or whether our approach of creating multiple branches itself is wrong in the first place.

Answer 1

My suggestion is that you study the TFS branching guide by Visual Studio ALM Rangers. It's quite some reading, but a good one, and you should be able to find a scenario there that suits you - and is advisable when using TFS. You find it here: http://vsarbranchingguide.codeplex.com/

Answer 2

I would say the question is much more about a business then about the technology to use.

Are you sure that this is your only customer that will need that kind of treatment from your company (I imagine it's important customer) ?

• Yes. In this case just make a branch. Setup automated test scripts. On every commit you made on the main branch that should be present also int customer branch make a merge. Run your nightly scripts to check integrity

• No. I would say do not make branch, at this point (at the end how much branches you gonna manage contemporary..) and use configuration option in the code. That means clear separation of the features available for one customer, or for another. The features can be available based on some configuration option available in your application's configuration file. If, you want to make the stuff more tricky, as clients are able to manipulate files, can invent License types (keys) whom computed hash aggregates not shared features availibility.

Unfortunately the branching is always headache in centralized code versioning systems. In distributed systems it's managed in much better way, but, by the way, completely avoid conflict, especially in long term run, is almost impossible in both cases.

Good luck.

Answer 3

I would suggest you create the branch for the released version, and on each subsequent release you make from that branch (since you're only making bug fixes), every time you release from that "bug fix branch", don't re-branch, but create a tag so you can reference easily.