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" <stsp_at_elego.de> wrote:
> On Fri, Nov 05, 2010 at 01:49:03PM -0000, 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
Received on 2010-11-05 16:04:34 CET