Stefan,
Your point well understood now. Thanks for the clarification,
appreciated.
Steve H
-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: 08 November 2010 17:01
To: Hutchinson, Steve (UK)
Cc: users_at_subversion.apache.org
Subject: Re: Svn externals question
>>>>> SPECIAL MBDA ALERT - SECURITY INCREASED FOR WEEK COMMENCING
>>>>> 08/11/10
PLEASE TAKE EXTRA CARE NOT TO CLICK ON HYPERLINKS WHERE YOU DO NOT KNOW
THE SENDER ANY SUSPICIOUS EMAIL, PLEASE FORWARD TO ftn.VIRUS CONTROL
<<<<<
*** WARNING ***
This mail has originated outside your organization, either from an
external partner or the Global Internet.
Keep this in mind if you answer this message.
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
********************************************************************
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
********************************************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Received on 2010-11-08 18:43:28 CET