Ok, this is another techy post, for which I apologise. I thought I should probably mention it, though, because if I mention it now I’ve got no excuse for not remembering it…
At work, we migrated our source control to Subversion last October. When the repository was created, it was a Berkeley-DB based repository. The past couple of days, I’ve read that the new default repository is a filesystem-based one (FSFS) – not just that, but there are advantages to using the filesystem based repository over using the Berkeley DB based repository. We’ve had a few issues where the database has needed recovery (see my previous post on Subversion…), which wouldn’t happen on a filesystem based repository. There are a few other things as well.
“So”, I thought, “I’ll create a new repository and migrate the data across” [as described here]. And the migration worked perfectly, I might say.
However, there was one thing which could have gone better, not the fault of Subversion but our fault: last year we didn’t have a build server, meaning that we would store binaries of the deployment files in Subversion so that if you wanted a build to install you could just get it out of the repository. That might seem like a good idea, but it’s really not: in the first 300 revisions in the repository, there are a large number of binaries, around 20 megs in size. We have approximately 1600 revisions in Subversion. Guess how long it took to migrate? The first 300 revisions took about an hour to migrate – the next 1300 took about ten minutes.
Anyway, my point is, deployment files (web application files, installers, that kind of thing) are not for source control. Use a build system like Maven, regularly build your installation files using a continuous integration system like Cruise Control, but don’t store them in the svn repository! That’s not its purpose… and it will make things very, very slow if you ever need to do a migration.
Leave a Reply