Can any source control system handle branching code base on a per client basis?

Question

We are presently using TFS 2010 to manage our Source Control(MS shop so it was the default choice).

We have no problems with it for our standalone projects. However we have a core product that we bespoke on a per client basis. Many clients require quite significant customizations, others only a few minor tweaks.

We are finding that it is a nightmare. We basically have a Team Project which contains the Core Product. If a client needs no changes they just get the core product deployed. If they ask for changes we branch the core product team project and start working on that.

So a single file needing changes requires then we branch the whole product. Are we doing this wrong? I kind of pictured we would create a branch that contains differences from the main product that each client needs. Then basically the client would get the core + any changes they require. Then if we add to the core or change it then they just get that automatically.

We are constantly developing the core so we seemed to spend our lives merging changes into all the branched projects. We presently have 5 clients but have 15-20 in the pipeline in the next year. However this would seem totally unmanageable given the work we are doing on 5. Our lives as programmers seem to be just merge after merge. Now this is partly as the product is quite new so there is a lot of churn for core. However we will always want to keep developing core. The problem is none of us have ever worked on a project like this so we just have no idea if this is how we should be handling it.

Does anyone have any thoughts?Really appreciate any suggestions as this whole core/branch/endless merge makes us sad. Someone suggested to one of my colleagues that git would help we would look at anything.

Thanks

Answer 1

Depending on how your code is structured, you may be able to take advantage of partial branches in TFS. Let's say your main branch is named "Main" and it has four subfolders: "a", "b", "c", "d". If you know you are only going to change "d" then you would only branch "d" to your new branch, which could be called "Feature1".

So, in TFS you would have this folder structure:

Main/
    a/
    b/
    c/
    d/

Feature1/
    d/

Now, the trick to making proper use of this partial branch is to set up the correct workspace mappings when you are working on Feature1. What you want is to have a/ b/ and c/ come from Main and d/ to come from Feature1. You could use the following mappings:

(active) C:/dev/Feature1 -> $/TeamProject/Main
(cloaked) $/TeamProject/Main/d
(active) C:/dev/Feature1/d -> $/TeamProject/Feature1/d

So, now, in your workspace, a, b, and c will be updated as they change in the Main branch and d will be only the changes in the feature branch. When you merge, only changes in d will need to be merged and resolved.

While this will solve your problem, you do need to understand that it is fairly complex. Nothing prevents you from accidentally checking in changes for a, b or c while working on Feature1 and those changes would go straight into the main branch. Also, by not isolating yourself from changes in Main, other developers could make changes to a, b or c that do not cause build breaks in Main but do cause build breaks in d (assuming d relies on a, b or c).

Here is a good link on how to create a partial branch.

One other note, you can create partial branches for files and folders at any level. You aren't limited to just top-level folders.

Answer 2

git gives you two advantages to TFS that might help you.

First, in git branches are simple and quick to create and don't demand the kind of planning and ongoing conceptual load that TFS seems to demand. Second, and most importantly, git allows you to move changes across your branches with a rebase rather than a merge; this can really help to keep the reconciliations clean and easy and to keep very distinct what is branch development and what is trunk.

Also, there is a nice tool, git-tfs, that lets you work with git while still keeping a repository in TFS. This can be great while you are making the transition to git, or if your company demands you keep a "master" repository in TFS going forward.

One caveat: while I think you'll find git works great for your situation, it is not a use case that is covered by much of the git documentation. Lots of git writing focuses on branching and merging while I think the advantage in a case like yours is branching and re-basing. It tends to take a period of use before you really "get" git and know the right thing to do when straying off the beaten path (and explaining how to do your use-case in detail is beyond StackOverflow's scope), so it might take a while before your team gets it down.

Answer 3

If your base product and your branched products have different versions of the same files, you'll end up with merges no matter what source control product you're using. Some (Git for example) make branching and merging fairly easy, some (like TFS) make it a pretty heavy operation, but the merges still have to be done.

One strategy that makes it quite a bit easier to handle is to break the code up into more manageable pieces (SOLID comes to mind) and break out any adaptions into customer specific classes. If there are separate files for the customer adaptations and the classes can be injected using just a configuration change, there won't be as much reason to branch for customer specific changes at all. The worst a change to a customer specific class can do is to break the customer you're developing for. That will keep branching for versioning (ie dev/test/release branches), but you won't get versioning and customer specific branches.