My work SVN repository is taking a while to update (see here for details). So I’ll just write a bit about the latest neat feature I’ve been benefiting from in Subversion: svn:externals.
The idea is an old one: link to another folder (or file) in a repository. The benefits of doing so are wonderful.
For each JSP project the following are commonplace:
- the tag library
- a folder for dependencies
- a folder for Java source
Now, I’ve been storing each of these in different parts of the repository. Given a project A its Java source exists in /source/branches/projectName/src, its compile-time dependencies in /source/branches/projectName/deps, and its tag library has been a SVN copy of the RELEASE tag of our jsp tag library.
What a mess it was: building the source was in a separate part of the repository (which aided things like testing and continuous integration) and one had to manually update a project when the JSP tag library had a new release. We also had to use a wonky build script I wrote in Ant to pull the resultant JAR file from the repository into the web project—it was annoying I tells ya!
Creating a new project now is much, much easier in Subversion: I just copy a template project and update its svn:externals property to point to the appropriate branch of my source tree. An update will then update the externals alongside the rest of the project, so my JSP tag library is always up-to-date, and a modification to the Ant build file means that compiling the web project is one step again. The best part: everything that was broken up remains broken up, which aids in the management of those resources. The JSP tags are a perfect example of this: someone who knows what they’re doing can work on them and update the RELEASE tag when they’re done. When someone who depends on those tag libraries does their next update (which is pretty much once a day at least) they automatically receive those changes without the JSP tag library person getting involved or (worse yet) invading my project in SVN.
Finally, since externals allows you to point to any SVN repository, you can remix and combine repositories really nicely. For instance, you can run a repo for web projects that links to the repo for Java sources which in turn links to the Spring Framework’s latest and greatest release as a dependency.
Hi, I’m learning Subversion and I’m trying to wrap my head around how externals work.What happens when there are several levels of externals? Imagine a project A that references projects U and V. In their turn, both U and V reference project X.So, if I checkout project A from the repository, will I end up with two separate copies of X down my directory? Or does Subversion detect this, checkout only one copy of X, and put symbolic links to it in the appropiate subdirectories of U and V?
Pingback: I Like Parentheses (so get used to ‘em) » Symbolic Links in Subversion pt. 2
Hi Tim!
When you checkout project “A”, you get all of its files and its metadata.
In its metadata, the svn:externals is set. Whenever you then update “A” you’ll then get a copy of “U” and “V”, each with their own metadata and files. When you then update “U” you’ll get a copy of “X” wherever you linked it to (ditto with “V”). They will be different copies of the same repo location!
Here’s a new post that hopefully answers your question with an example.