Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Chakra, >>> one CVS project for each customisation, or ... >>> labels and tags for (each customer + each version for the customer) The general answer would probably be to use one project with tags and branches for each customization. However... What percentage of the code base will tend to be common versus customized? If most of the code base is common, then I believe you definitely want to use one project. In that way, a bug will usually have to be fixed in only one place where it will be seen by all customizations. If you kept different projects per customer per version, then one otherwise minor bug could result in a big update effort in each of the many variants. On the other hand, if a significant part of the code is to be customized (meaning, in part, that finding a bug in one does not nescessarily mean that bug is in the others), then separate projects would probably work well. You could factor out any common code into its own project that is then used by all of the customizations. A related consideration is whether one set of developers maintains all the customizations, or do you have different sets of developers. One set of developers would probably find it easier to work with one familiar project with branches while multiple developer groups would probably prefer separate CVS projects. One final consideration: What kind of customizations are you talking about? If they are the type of things that can be handled by config files (e.g., GUI color schemes, hardware configurations, I/O parameters, etc.), then use one project with different config files. You might not even need branches. Are the customizations mainly independent features such that tend to appear in one customization and not the others? If so, one project where different sets of files are compiled for each customization would work well. Having said all of the above, there is a higher level view of your question: How do you want to organize your developement effort such that if you have N customers with M versions, you do _not_ end up with N*M unique pieces to software to devleop and maintain? Are you going to try to isolate the differences to certain files? Are you going to try to parameterize one set of code with config files? Are you going to have a base project with independent add-ons? Once you decide how you want to structure your product to allow customizations, you will have a much better idea of how you want to represent it in source control. Merrill