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 -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
