Time to time I help my friends with system configuration and other “wtf? it worked yesterday!” kind of issues. One of them runs a thematic torrent tracker that has a certain popularity and medium-sized community around it. The tracker itself is based on a heavily modified TBDev code with some performance fixes and functional additions, and it was forked so long ago that I’m not even sure how closely it relates to the official TBDev branch now. And these guys have about 30,000 registered users stacking up to 100,000 simultaneous upload/download activities.

But that was all quite irrelevant, just to give a broad picture. A couple of monthes ago this tracker was upgraded to the second server – it was running on a single server before that has started to choke. And after the upgrade everything was running fine and fast with a plenty of extra resources to spare until yesterday, when this guy came to me with the words: “Damn, man, looks like we already need yet another server, everything is hell slow and just dying here”.

Of course, my first reaction was “WTF?”. They were running happily last week, and suddenly – overloaded. Hell no, this stuff just never happens.

So let’s say you have some big codebase in Git repository. Or maybe not even that big, but with a complex dependency added in as a submodule. And this submodule is complex enough that it makes sence for it to reference other project and include them as submodules, too. Sounds too complex? Well, maybe it is, but there’re certain situations when this workflow is plausible, especially if your upstream uses Subversion instead of Git. Symfony comes to mind as an example – huge framework with a number of dependencies (look at version 1.2) that uses svn for development.

You’ve found a good guy at GitHub doing svn clone of upstream’s repository periodically, you’ve pulled his git repo as a submodule, initialized and updates submodules and things look good so far. Feeling lucky, you’re dropping in you Capistrano config, customizing it with your server and repository details, and finally typing your magical “cap deploy”. Still feeling lucky and going to grab that hard-earned cup of coffee? Well, hold on there for a minute and pay some attention. Whooops! What’s this? That bloody thing fails.

The problem here is that Capistrano by default (by that I mean when you have :git_enable_submodules settings in your config file) only issues “git submodule init && git submodule update” at the root of your checked out repository, so if you application depends on any submodules down the tree to be initialized, too – well, “Screeewed!” © GoW2