CODEWITHSUNDEEP
svnversion-control
Gambo
Gambo

Reputation: 1572

Project Structure for Product with Different Versions

we want to develop a product and deliver it to several customers. Now we have the case that some customer want to have an additional feature x and another customer want to have feature y. Some of the features also need some changes in the software architecture of the product.

And all customers of course want to benefit of the official features definied by all customers.

Now my question is how to handle this at the best? We are currently using SVN for versioning and this works really well as long you one trunk and the possibility to create tags.

I know we can create several trunks for each customer and then merge all features into the several customer trunks but this is a lot of manual work and could get messy very quickly.

Thanks for your help

Upvotes: 2

Views: 1904

Answers (1)

Neville Kuyt
Neville Kuyt

Reputation: 29629

This is a big, hairy topic - Martin Fowler has a great write up of Feature Branching (http://martinfowler.com/bliki/FeatureBranch.html); there's also Branch by Abstraction (http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/).

The big risk is that you end up using SVN as a stand-in for a "proper" architecture. If you need to support multiple features in this way, you should probably architect the solution to support this at run time (through configuration), or at build time (through configuration); the common way to do this is to use plug-ins.

Using your source code control system to "merge in" features makes the merging process into an unpredictable, unstable mess - the fact you can merge in code from another branch doesn't mean that it will all make sense - and the developers working on the different features/branches may be duplicating each others' work, or making mutually exclusive decisions on design.

Upvotes: 3

Related Questions