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.
Gabriel.
---------------------------------------------------------------------
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:36:46 2006