Version Control for Third Party Software
I had an email response from Mike to my earlier post on personal version control.
… What’s your take on third party sources? We had a discussion today about putting CPPUnit under CVS control for instance and didn’t really come to a solution. Do we drop the raw source download into CVS? Or do we build it first and just import the headers and libraries? Or do we just copy the headers and libraries into the project-under-test’s source tree? Be interested to hear your thoughts.
Coincidentally, this comes at a time when:
- I’m busy putting some third party code under source control, and
- I find myself using CVS rather than Subversion.
Back to CVS
If I had to use a version control system which wasn’t Subversion then it would be CVS, no question. CVS is excellent, but — in my opinion — Subversion is better in just about every way. Fortunately it isn’t too hard to switch between the two: Subversion at home, CVS at work. Of course, it’s technically not that hard to migrate a CVS repository to a Subversion one, but I digress …
Version Control for Third Party Software
Question: When should you put third party software under version control?
Answer: It depends.
Question: When should you put third party source code under version control, and when should you put in pre-built binaries?
Answer: It depends. You can always do both!
The goal, I suppose, is to be able to build your product starting with nothing more than access to the version control system. This is a little simplistic. For a start, you can’t access the version control system unless you have the client software installed. And what about a compiler? Are you going to check out GCC and build it from source? Probably not. Though, if your product happens to be a Linux distribution, maybe. Clearly, a line has to be drawn.
I think it’s fairly clear which side of the line CPPUnit lies on.
Putting CPPUnit under version control
In Mike’s case, I think right the choice is fairly clear. CPPUnit is only available as source code — there are no pre-built libraries for different platforms.
This means that you’ll have to figure out how to build it yourself and how to integrate it into your product, which is a non-trivial activity. Even if you do decide, for convenience, to check the derived libraries into the version control system, you’ll want to make sure that you also check in the source itself and the build scripts, so you can regenerate the libraries easily.
Ideally, though, you just check in the source code and the derived files are handled directly by your build system. If the build system is sound, a simple dependency check means you won’t waste time regenerating the libraries.
In fact, if you don’t intend to tinker with the CPPUnit source, you might even just check in the tarred and zipped archive — exactly as downloaded from SourceForge — and have your build system unpack and build it.
Vendor Branches
Both CVS and Subversion have a concept of vendor branches. Vendor branches are used to manage third party code, and also to manage any changes you make to this code. Thus, if you decide, at some point in future, to upgrade to a newer revision of CPPUnit, you can do so in a way which merges in any local modifications you made to your current version of CPPUnit.
This is a bit fiddly — in both CVS and Subversion. If you can avoid such modifications, or apply them directly to the code in the CPPUnit SourceForge project, I’d suggest you do.
Subversion Externals
If you use Subversion you might also consider using an externals reference to the third party code. But that will have to be the subject of another post.
Articles