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)
Workflow of sharing code for small teams
version control;visual studio 2010;workflows
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).