This might seem a little off topic, and a long read, but might be useful
for thinking about your problem:
https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.1g117atv5
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
decoupled.
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.
Eric.
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.
