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.
>
> Gabriel.
>
We are struggling with this problem too. We have hundreds of projects in
dozens of repositories, some sharing libraries and tools.
I've been kicking around the idea of an indirect repository link for
externals. The idea is that instead of svn:externals pointing to the
actual repository, it would just have a unique name for the external
project plus the relative path within that project. Another database
would map the unique name to the repository location. This is similar to
using relative paths with an extra level of indirection. The svn client
would have to know where the externals mapping database is, but it would
allow you to shuffle projects around as needed without affecting the
externals links.
-- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 28 17:11:25 2006