Problem is, we have developed a small CMS, that is different per implementation (currently).

Of course development of this is never complete. Sometimes, we are working on more than one project that implements it (by copying-pasting the code files of the CMS to each project), and we add a new feature that we want to share on other projects as well (these can be small ones too, ie a custom ajax JSON controller - we use MVC)

What we want to do is quickly and uniformly share the code with all other projects, via a version control system (or something similar), and generally organize the workflow as we know this isn't a very good workflow that we have. What would you suggest?

Also, at the momment, the software we use is Visual Studio 2010, so we are strongly considering TFS, but even if we get it we still don't know the ideal workflow, or even if TFS supports what we want to do.

Edit: Also note, we have specific implementations that have modifications over the CMS base that we want to KEEP only in the project area. (ie: a specific feature that we DONT want to share with the base CMS code)

  • +1 for understanding that by copying-pasting the code files of the CMS to each project is wrong. There are so many out there that somehow fail to do so. Walkthrough: Exploring Team Foundation Version Control
    – yannis
    Commented Nov 25, 2011 at 9:21
  • Thanks for the link, I'm also exploring This extended guide but I'm not looking for a specific user guide but rather a concept guide Commented Nov 25, 2011 at 9:27
  • Yeap, I got that, that's why I left a comment and not an answer. But it's highly unlikely that a conceptual guide will be tailored to the specifics of your question, that's something you'll have to do yourself, so along with any answers you'll get here you should start reading up on TFS.
    – yannis
    Commented Nov 25, 2011 at 9:32

2 Answers 2


This is not a problem of selected version control but the problem of product architecture. There is very similar question where you find that you are not the only one challenged with this problem.

General advice is avoid any copy-paste between implementations. This can be obviously done only if you have single branch for core of your product and customer specific features are implemented in separated branches (but without the core) or via configuration of your product. Once more than two customers want the same feature it is time to move the feature to the main branch and make it reusable and configurable (so it can be turned off for customers who don't want it).

As you can notice I mentioned "more than two". This is my own assumption about reusability to weight costs needed to transform feature to reusable and globally available. I consider two customers requiring the same feature still not feasible for this effort. Also two customers are usually not enough to define reusability but collecting requirements from three or more customers usually result in good set of requirements to define reusable and configurable feature.

There are other problems with multi-customer application. For example if you sell the application and customization instead of application or service you can have problems with this because implementing the new feature directly for customer (in time payed by customer) can lead to situation where the feature itself is property of your customer and you cannot use it for other customers (even if they want it) until the owner of the feature allow it - sell you a license (but this problem can already exists in your current situation as well if you don't have correct agreement with your customers).

  • Thanks for the insight and also the link. On the legal part we are covered, thankfully. After a lot of reading this is exactly how we are going to go on from here, using TFS as the medium. Commented Nov 25, 2011 at 14:09

First off, you should indeed use source control - this is less a means for sharing as much as a means to ensure that changes are recorded.

In regards to sharing of code - you need to identify the common parts of these applications, the things that do not change. Take these and create a project from them (or even a set of projects) - ideally things that are pure code and no markup. This can then produce a shared DLL to be used by all of your customized projects.

As for the markup - you could do something similar, but the UI tends to differ between projects, so I don't know how much use that will be.

  • Unfortunately this is not an option as the CMS also contains basic media, js scripts for client-side integration and so on Commented Nov 25, 2011 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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