[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-26 23:40:29 CEST

On Jul 26, 2006, at 21:54, Gabriel Cooper wrote:

> I'm currently in the process of making a duplicate of a web server
> for an important client. Thing is, the sites on the box haven't
> been touched in any significant way for over four years. That being
> said, many of the tools used to create the web server are versioned
> far ahead of what is compatible with the sites today and some very
> important pieces were some time ago deprecated and eventually
> removed from the internet entirely!
>
> While looking at a new project that uses SVN externals it occurred
> to me to wonder whether externals would solve this problem. If my
> cursory digging and understanding is correct, the way externals
> work is that instead of needing a local copy of a library and
> needing to manually keep it up to date, externals will
> automatically do this for you by looking at the originating source
> you tell it to and pull from there instead of the local repository.
>
> So. Thinking long term, what would happen if the scenario above
> pertained not to installed programs, but to software libraries
> obtained from external sources? If your external repositories from
> http://svn.somewhere.com/ImportantLibrary disappeared, would you
> have access to your library anymore?
>
> If I understand correctly, you would not. It would attempt to look
> for the latest version of your external repository and fail fail
> alltogether. And so presumably you'd be left with a non-functioning
> application.
>
> So why not then keep a local copy of the repository and have
> externals function such that it merely verifies that your
> repository has the most up to date files before it commits them?
> That way even if your foreign repositories disappear your files
> won't and your application will continue to run smoothly.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 26 23:41:42 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.