If you do switch to the approach Stefan suggests (and I agree, it's probably
more satisfactory) you also might want to use svn switch instead of the
svn:externals. You'll still have the auditable, versioned definition of your
canonical configuration (in the form of the script), but also there will be
more freedom for variations, such as while preparing a new configuration.
Sent from my iPhone
On Nov 5, 2010, at 10:09 AM, Stefan Sperling s...@elego.de wrote:
On Fri, Nov 05, 2010 at 01:49:03PM -, Hutchinson, Steve (UK) wrote:
Hi,
Currently we are attempting to use svn externals to help build various
projects from what I would call a few reuse repositories. We are
attempting to be structured as to what level of design hierarchy we
apply the properties but sometimes when we inherit a design people can
spend a bit of time trying to identify where externals have been used.
Is there a simple way of identifying in a structure folders that have
external properties, come to think of it maybe any form of property ?
The designers of the externals feature envisioned maybe a handful
of external library dependencies that don't vary much over time.
These are automatically pulled into a working copy, much like an automated
svn checkout.
But the design doesn't account for what happens when people start using
svn:externals for variant management or large-scale component reuse.
If you're pulling together project components from externals in various
combinations, like lego blocks, or simply have many externals, don't use
the svn:externals properties as the primary source of your configuration data.
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.
You can query a file or a database easily to find out which components
are used where. But svn properties haven't been designed for this use case.
You cannot query a Subversion repository like you can query a database.
Well, you could crawl the repository, but that's quite slow.
Hope this helps,
Stefan
