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/vendo
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:
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.
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.
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.