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
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.