What's the benefits of "svn:externals"?

Question

I would not get to know svn:externals if I haven't run into the this page. So, I setup my working folder. Then

mkdir lib/vendor
svn add --parents lib/vendor
svn ps svn:externals 'symfony http://svn.symfony-project.com/branches/1.4/' lib/vendor/
svn ci -m "add externals"
svn update

The "svn update" enlists the whole symfony folder and is pretty slow. I thought that would be single time pain. However, SVN will check external repository every time I typed "svn up". I have to use --ignore-externals to make "svn update" fast enough.

I'm wondering what's the benefits of svn:externals if it is so slow. I'd rather copy symfony to my own repository, which is surely a faster solution.

Answer 1

The way you use externals is for people who want to work on the head revision of some code, for example if you are on an internal project where all kinds of libraries and applications are co-developed. Usually, you should not do this without good reason, because a code revision in an external might break your code - and if you have no right to fix the external, then working with it becomes a bit cumbersome.

You can either fetch a specific revision of the external repository into a so called vendor branch of your own repo, or add a revision argument switch to your externals definition, like explained here for example:

http://thinkinging.com/2008/10/21/set-the-revision-of-your-svnexternals-or-else/

Answer 2

The svn:externals mechanism is behaving as advertised. The problem is that you are using a public subversion repository (accessed over the internet) inside what I assume is a local repository. As a result, you are seeing a significant discrepancy in the time to update the internal repository vs. the externally referenced one.

Copying to your repository is certainly a viable solution. How to do this is explicitly documented in the Subversion book.

Answer 3

SVN externals also have a lot to do with project organization. Externals can be completely different SVN repos, which means you can set up different types of security, protection, access, pre-commit hooks, post-commit hooks, etc... It's difficult to do different levels of access for different folders inside of a single SVN repo (without the help of something like VisualSVN), and it's very difficult (and possibly unwise) to try and do different backup or security method for different folders inside of a single SVN repo. Externals allow us more freedom by allowing us to stitch together several different repositories with a single svn up.

Subversion Externals Use Cases:

1. A common use case is for an external to contain a library or some other piece of immutable code. If you have a .dll you can absolutely just plop it into your SVN repo and treat it as part of your code-base, but you've covered up the fact that the .dll should be treated as read-only and wasn't developed by you or your team.

2. Another use case (which you have discovered) is to allow your libraries to remain on a remove repository - perhaps one maintained by an active open source project. In this case you could always point to a specific version of an external and not worry about storing it yourself.

3. Finally, externals can pull in trunk, branches, or tags, which means that you can use them to stitch together a project that is composed of different tagged versions of your own modules. This would more closely mimic something like Rational ClearCase or any other large Version Control System. You would do this by maintaining an SVN repo for each module or component of your code-base, create a tag of each mode/component, and then reference the tags using the externals property of a master repository - which exists just to pull them together into a working project.