[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Component mangement and Subversion

From: Eric Johnson <eric_at_tibco.com>
Date: Fri, 17 Jun 2016 09:53:33 -0700

This might seem a little off topic, and a long read, but might be useful
for thinking about your problem:


Unfortunately, the answer you seek probably depends a little bit on what
language you're working in, because different languages bring different
tool kits to the table.

The dependency resolution problem usually ends up being tied to a
particular build system, because the build system designers feel like
they need to own the problem. Would be great if it was instead generally

In any case, it is probably a bad idea to combine built artifacts of any
sort with your source code tree. They tend to get in the way - taking
longer to download a working copy, changing frequently, and possibly
taking up lots of space. Combining external source code in your source
build tree, via any means (such as svn:externals), is probably just
fine, so long as the external source does not swamp the size of the
local code.


On 6/17/16 8:39 AM, Ignacio González (Eliop) wrote:
> Hello.
> 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:
> 1) Yes, do use svn:externals! (with some structure and planning
> ahead). This is the approach proposed by John Martin in Reusable
> Component Management Through the Use of Subversion Externals (
> http://www.bcs.org/upload/pdf/reusable-component-mgt-jmartin0708.pdf
> ). It's perhaps a bit dated, but it presents several good ideas, I think.
> 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.
Received on 2016-06-17 18:53:41 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.