[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Storing externals for future generations?

From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
Date: 2006-07-27 22:49:25 CEST

On Jul 27, 2006, at 22:37, Gabriel Cooper wrote:

> Ryan Schmidt wrote:
>
>> Your assessment sounds just about correct. The 3rd-party library
>> doesn't even have to disappear entirely for it to cause problems
>> for you -- they could decide to switch from Subversion to a
>> different version control system, or their server could merely be
>> inaccessible for a few hours at just the wrong time.
>>
>> For my projects, I've been therefore following the vendor branch
>> strategy, where I import 3rd-party software into my own
>> repository. This has the added advantage that I can make local
>> modifications to the 3rd-party software if I want to, and track
>> those changes, and still be able to upgrade smoothly to newer
>> releases.
>>
>> http://svnbook.red-bean.com/en/1.2/svn.advanced.vendorbr.html
>
> It seems the idea of a "local external" would be beneficial for
> those that want the benefits of svn externals but want to be kept
> up-to-date so they're not crippled should that external disappear
> unexpectedly.
>
> One possible implementation would be a hybrid with the Vendor
> Branch idea: Create a vendor repository then run a "local external"
> command which imports the off-site directory into the specified
> local repository /and/ marks the directory as an external. All
> local projects then reference the local vendor repository as an
> external and any time one of those local projects is checked out it
> cycles through the local externals, updates them to the latest
> code, then exports their data to the working copy. With a simple
> flag the functionality could override whether it looks for new
> versions of the external or uses the local repository's code.

I don't understand your proposal. Can you show a set of commands that
gives a demonstration?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jul 27 22:50:55 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.