I'm looking for examples on how to use Subversion efficiently in the context of component management.
We develop some products that we have to adapt to different markets. Some of the features are common, some are partially common, and some are unique for each market. Sounds like the definition of product variants, doesn't it.
We decided some time ago to use more and more a component approach for those software products, in order to maximize their reutilization in different variants, and to minimize the typical maintenance problems of fixing / enhancing / modifying common and non-common parts of the software.
Now we are using (abusing?) svn:external across different branches of our product variants, but we are afraid of escalating problems when we have even more variants, more products and more systems of products.
So I have researched a little (read: I have used Google) and I have stumbled upon three different approaches to the problem:
2) Well, you'd better use something outside Subversion to do the real component management (a --possibly versioned-- file, a database...), and, at most, use some kind of script or the like to maintain a set of svn:external properties in the repository. This is the advice that my admired Stefan Sperling gave in this forum some time ago ( http://svn.haxx.se/users/archive-2010-11/0097.shtml
3) Please, use our specialised tool for modelling and managing your product line and regard Subversion only as a revision control system to deal with later
I’m tempted to follow Stefan’s advice, but I would be grateful to have more specific examples on how others are implementing it (if any), or how others are using John’s solution, or if there are other possible approaches (examples, articles, links, even products) that could help me.
Thank you very much for your time.
Saludos / regards
Ignacio G. T.