Are subversion externals an antipattern?

Question

Subversion lets you embed working copies of other repositories using externals, allowing easy version control of third-party library software in your project.

While these seem ideal for the reuse of libraries and version control of vendor software, they aren't without their critics:

Please don't use Subversion externals (or similar in other tools), they are an anti-pattern and, therefore, unnecessary

Are there hidden risks in using externals? Please explain why they would they be considered an antipattern.

Answer 1

The main risk with using svn:externals is that the referenced repository will be changed in a way that breaks your code or introduces a security vulnerability. If the external repository is also under your control, then this may be acceptable.

Personally, I only use svn:externals to point to "stable" branches of a repository that I own.

Answer 2

I don't think this is an anti-pattern at all. I did a few quick searches on google and came up with basically nothing... nobody is complaining that using svn:externals is bad or harmful. Of course there are some caveats that you have to be aware of... and it's not something that you should just sprinkle heavily into all of your repositories... but as for the original quotation, that's just his personal (and subjective) opinion. He never really discussed svn:externals, except to condemn them as an anti-pattern. Such sweeping statements without any support or at least reasoning as to how the person came to make the statement are always suspect.

That said, there are some issues with using externals. Like Mike answered, they can be very helpful for pointing to stable branches of released software... especially software that you already control. We use them internally in a number of projects for utility libraries and such. We have a small group that enhances and works on the utility library base, but that base code is shared across a number of projects. We don't want various teams just checking in utility project code and we don't want to deal with a million branches, so for us svn:externals works very well. For some people, they may not be the answer. However, I would strongly disagree with the statement "Please don't use..." and that these tools represent an anti-pattern.

Answer 3

If plain external is an anti-pattern because it can break your repository, then one with explicit revision should'nt.

Excerpt from svn book:

An externals definition is a mapping of a local directory to the URL**—and possibly a particular revision—**of a versioned resource.

I think it's all depend your purpose of using the feature, it is not an anti-pattern by itself.

Answer 4

There are definite flaws in subversion externals, but we seem to use them reasonably successfully for including libraries (both our own and vendor) that the current project depends on. So I don't see them as an "anti-pattern". The important usage points for me are:

• They point to a specific revision or tag (never the head) of the other project.
• They are inserted into the current project well away from its own source code etc (e.g. in a subdirectory called "support files").
• They refer only to the other projects "interface" files (e.g. include folder) and binary libraries (i.e. we don't get the full source of the other project).

I too would be interested in any major risks of this arrangement, and better approaches.

Answer 5

Saying that a is b does not make a a b unless you say why this is so.

The main flaw I see with external references in subversion is that you're not guaranteed that the repository is present when you update your working copy.

Subversion external references can be used, and abused, and the feature itself is nothing but just that, a feature. It cannot be said to be a pattern, nor a antipattern.

I've read the answer by the person you quote, and I must say that I disagree. If your project requires files version XYZ from a repository, an external subversion reference can easily give you that.

Yes, you can use it wrong by not specifically specifying which version of that reference you need. Will that give you problems? Likely!

Is it an antipattern? Well, it depends. If you follow the link given by the author of the text you quote, ie. here, then no. That something can be used to provide a bad solution does not make the entire method of doing so an antipattern. If that was the rule, then I would say that programming languages by and large are antipatterns, because in every programming language you can make bad solutions.

Answer 6

An old thread, but I want to address the concern that a changing external could break your code. As pointed out previously, this is most often due to an incorrect usage of the external property. External references should, in almost all instances, point to a specific revision number in the external repository URI. This ensures that the external will never change unless you change it to point to a different revision number.

For some of our internal libraries, which we use as externals in our end-user projects, I've found it useful to create a tag of the library at Major.Minor version, where we enforce no breaking changes. With a four-point versioning scheme (Major.Minor.BugFix.Build), we allow the tag to be kept current with BugFix.Build changes (again, enforcing no breaking changes). This allows us to use an external reference to the tag without a revision number. In the case of major or other breaking changes, a new tag is created.

Externals themselves aren't bad, but that doesn't stop people from creating bad implementations of them. It doesn't take much research, just a little bit of reading through some documentation, to learn how to use them safely and effectively.