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