The procedure Brion used for the last couple of wmf-deployment updates was:
* Create a new branch wmf-deployment-<date>, copied from trunk * Spend a day or two merging in all the WMF-specific hacks and merging out anything that's experimental or buggy * Delete wmf-deployment * Move wmf-deployment-<date> to wmf-deployment
I'm considering instead creating a permanent numbered branch for each wmf-deployment major update. To deploy a major update, we would use svn switch to change the checked-out directory. Then subsequent minor updates would be merged to the most recent numbered branch.
The main advantage would be that the logs would be easier to navigate. Currently, if you want to know what happened in the wmf-deployment branch before the last major update, you have to specify path revisions to svn log, which is tedious and potentially confusing. Navigating the history in viewvc is also difficult.
Another advantage is that we'd have a major version number that we can say Wikimedia is running on. We had three deployments of 1.16 and there may be a fourth before we branch it and start on 1.17, but these branch points are unnamed. Instead we could call them 1.16wmf1, 1.16wmf2 and 1.16wmf3 in Special:Version, and we could keep track of when those updates were deployed, so that users would have a better idea of how to talk about the software that we're running.
I've used svn switch a few times in other situations, and haven't encountered any problems with it. As long as there are no uncommitted patches in the live working copy, it should go ahead without a hitch.
Any thoughts on that?
-- Tim Starling