On Fri, Nov 5, 2010 at 3:09 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Nov 05, 2010 at 01:49:03PM -0000, Hutchinson, Steve (UK) wrote:
>> 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,
For finding the folders that have the svn:externals property, how about:
svn propget -R svn:externals TARGET
where TARGET can be a working copy path or a url. For a url it will
not be fast, but it works (for a working copy it works quite fast).
I do agree with Stefan though, that it's best to have another
"canonical source" for this kind of configuration data, especially if
it starts becoming more and more complex, and to derive the externals
configuration from that.
Received on 2010-11-05 17:13:08 CET