Stefan,
Your point well understood now. Thanks for the clarification,
appreciated.
Steve H
-Original Message-
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 08 November 2010 17:01
To: Hutchinson, Steve (UK)
Cc: users@subversion.apache.org
Subject: Re: Svn externals question
On Mon, Nov 08, 2010 at 10:24:03AM -, 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
Hi
>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
use another answer to continue that thread.
Regards
Steve H
-Original Message-
From: David Weintraub [mailto:qazw...@gmail.com]
Sent: 05 November 2010 16:17
To: Hutchinson, Steve (UK)
Cc: users@subversion.apache.org
Subject: Re: Svn externals question
>>>>> SPECIAL MBD
On Nov 5, 2010, at 11:54, David Weintraub wrote:
> The big problem with svn:externals is that they don't version very well.
> The problem is that the external directories themselves aren't tagged
> or branched when I did my tag or branch
If this is important to you, then you should use the svnco
On Fri, Nov 5, 2010 at 10:09 AM, Stefan Sperling wrote:
> 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 de
On Fri, Nov 5, 2010 at 9:49 AM, Hutchinson, Steve (UK)
wrote:
> 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 ?
Not 100% clear what you're looking for. You could be looking for one
of two things:
1). Yo
On Fri, Nov 5, 2010 at 3:09 PM, Stefan Sperling 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 t
On Fri, Nov 05, 2010 at 11:03:58AM -0400, Jack Repenning wrote:
> 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
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
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
> a
In a checked-out working copy, "svn status" marks directories loaded by virtue
of svn:externals with an 'X'.
Other props, and finding even that one from the repository, requires scripting
a loop to use "svn plist" or similar, I believe.
Sent from my iPhone
On Nov 5, 2010, at 9:50 AM, "Hutchi
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
13 matches
Mail list logo
