Let's say that we have an application, with two (or more) different versions. E.g. Professional and Lite editions.
What would be the best way to keep the source under version control (DVCS in particular). The assumption here is that some or most of the code is common, but the Professional edition has some extra code as well.
What would be the optimum way of versioning the code with a system like git or Mercurial?
Use the modularity of your language to organize a software product line, rather than the version control system. Quite simply, the merge process is not something you want to be a regular part of building your products. Rather, the design of your product should already take this into account.
By accounting for the software product family at the design level, this will also make it much clearer to developers what the variation points are: the variation points will be obvious in the design, rather than implied as source code differences.
This will ease developer testing as well: Any modifications you make should be tested on both products. You won't want to be making the same change twice, or constantly merging and undoing changes as they occur.
Review the literature on software product lines to see the best practices for your language. Using these techniques, you can create a third "product" that is streamlined for testing. For example, using dependency injection can be your mechanism for both testing and for having variants of the same program.
Whether it is with a DVCS or a CVCS (centralized), the idea is to define two "modules" (set of files) with:
Then you can organize them as sub-repos (Mercurial) or submodules (Git)
(or "external" with SVN", or...)
Not much idea about the git or Mercurial. The common feeling is you should have common part in one branch, and other versions in separate branches. When you are building, your build should be intelligent enough to check out code from appropriate branches and compile.
