There’s an interesting thread on SCM for Product Variants running on the CMCrossroads site at the moment.

One of the comments in the thread is that SCM is not a good solution for implementing variability as it is in fact an anti-pattern; there are better approaches to variability management and so these should be used in preference.

I think the key point is that SCM shouldn’t be the sole mechanism for variability management in most product lines. If you can answer yes to any of the following questions then you should probably consider whether you need to place less emphasis on using SCM as your variability management mechanism:

• Have you written a special application to extract the right software from your SCM system for a product build?
• Are you spending an increasing amount of time maintaining your SCM system and processes at the expense of developing new product features?
• Do you have branched code that could be reused between variants but you haven’t got the time or resources to merge the branches?
• Do you have difficulty building a valid configuration? Is there disproportionate amount of manual work involved? Are configuration errors common?
• Do you need a configuration expert to do your builds? What happens when they aren’t around? What happens if they leave the organisation?
• Can you explain why a product variant was configured in a particular way?
• Do you know the scope of your product line? Can you explain to your marketing group why you cannot (or can) build a specific variant?
• Do you have the need to produce variant requirement specifications, variant test plans, variant user documentation or any other non-software variant?

Mark