On Mon, Nov 08, 2010 at 10:24:03AM -0000, Hutchinson, Steve (UK) wrote:
> >Do it the other way: Store your component configuration in a versioned
> >file or even a database, and write a script to configure svn:externals
> >properties based on that data. Maybe even add an automated check into
> >the mix that makes sure the svn:externals in the repository's HEAD
> >revision >are in sync with your primary externals configuration source.
>
> I think unfortunately this is where you lose me :) I am not too sure why
> this is too different from "the other way". In both situations I end up
> with a set of project folders with svn:externals on them..... but the
> latter I say have one top level "externals.lst" and associated script
> file that is used to apply them. Probably a reflection of my knowledge
> level but not clear where the gain has come from ?
It depends on what you need to do with information about your modules.
It also depends on scale.
If svn propget -R output is sufficient and fast enough for you,
then you don't need a separate database of externals information.
In this case you simply haven't scaled up your usage of externals to
the point where propget -R becomes inhibiting.
E.g. if you need tool support to configure and compose your modules or
variants because you have a lot of them (say, various kinds of embedded
devices built from common parts), having the configuration data in svn
properties means that an application has to crawl the repository to
figure out which components are used where.
Also consider that you need might to crawl more than one revision
to find an answer you're looking for. A database can instantly tell you
things like "this component is no longer used, and was last used in
devices A, B and C." if fed a proper query. If such information is
hidden in externals in past revisions, you're putting unnecessary load
on your Subversion server by trying to track down the right properties.
Stefan
Received on 2010-11-08 18:01:41 CET