Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
Would the applications share code? What language? –  user1249 Dec 23 '10 at 17:30
    
Of course! Most of the code is common. The languages used are mostly C#, JavaScript, SQL and HTML. –  Nikos Steiakakis Dec 24 '10 at 7:07

3 Answers 3

up vote 8 down vote accepted

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.

share|improve this answer
1  
I really like the Product Line approach because this is mostly what we need, and as most answers prove, the choice of version control is irrelevant. Perhaps I was thinking more in terms of Developer A working on the main core, whilst developer b works on the feature of the Pro version and having the changes merged etc. But that does not have to do with the version control model. –  Nikos Steiakakis Dec 24 '10 at 7:09
    
Does this actually answer the question? (Not that I am disagreeing with anything that you have said, mind you). –  William Payne May 30 '12 at 22:58
    
@WilliamPayne: It's an alternative to the problem posed. (I would not recommend using version control for the above purpose. If you were to, however, a DVCS like Teamware/Hg/Git is the way to go.) –  Macneil Jun 7 '12 at 19:42
    
@Macniel: I strongly agree with everything that you have said so far. Furthermore, I believe in the notion that development cost control & cost amortization through software reuse needs to be explicitly factored in to the organization's management and financial structure through the use of product line centric organizational structures. I also believe that the structure of the source document repository used by the organization is a quick and easy way to communicate organizational structures and axes of reuse. This is largely an extension of Conway's law. –  William Payne Jun 7 '12 at 20:48

Whether it is with a DVCS or a CVCS (centralized), the idea is to define two "modules" (set of files) with:

  • one being the common code
  • the other being the features for the "pro" version

Then you can organize them as sub-repos (Mercurial) or submodules (Git)
(or "external" with SVN", or...)

share|improve this answer

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.

share|improve this answer
    
What do you mean by branch in this situation? I always understood "branch" to mean an independently progressing line of development for a particular entity. So given a repository with two branches, A & B, the contents of A should be expected to overlap with the contents of B to a significant degree. I would be rather keen to keep the notions of branches, versions and product features as orthogonal as possible. –  William Payne May 30 '12 at 23:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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