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.
Received on 2016-06-17 18:53:41 CEST