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
2010/1/12 Tim Starling tstarling@wikimedia.org:
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.
This part is what gets me excited most (sane version numbering), but not messing up the logs is also very nice.
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.
That's my experience yes. However, there are currently 11 locally modified files in wmf-deployment, so that'd need to be cleaned up first.
Roan Kattouw (Catrope)
Domas Mituzas wrote:
As long as there are no uncommitted patches in the live working copy, it should go ahead without a hitch.
Unfortunately, these will always exist.
Not really. I can commit or revert them while you're sleeping and do the svn switch before you wake up and mess things up again ;)
How will wmf-deployment -> trunk merge be done?
With great difficulty, but that's beside the point.
-- Tim Starling
Not really. I can commit or revert them while you're sleeping and do the svn switch before you wake up and mess things up again ;)
damn, gotta make a backup of livehacks then ;-))
With great difficulty, but that's beside the point.
OK! I was just wondering if there'd be any practice that would be helping you.
Domas
Domas Mituzas wrote:
Not really. I can commit or revert them while you're sleeping and do the svn switch before you wake up and mess things up again ;)
damn, gotta make a backup of livehacks then ;-))
There's a server called mayflower which would be a good place to put your backups. We even have a script to back things up to there, it's called "svn ci".
With great difficulty, but that's beside the point.
OK! I was just wondering if there'd be any practice that would be helping you.
Basically by reviewing every change that's been made to the branch since the last branch point, and ensuring that it's properly merged to the new branch or discarded. The technique is called "hard yakka" in the local dialect of English.
http://en.wiktionary.org/wiki/hard_yakka
-- Tim Starling
2010/1/12 Domas Mituzas midom.lists@gmail.com:
OK! I was just wondering if there'd be any practice that would be helping you.
The right way to do this is by committing your live hack to trunk first, then merging it to wmf-deployment-whatever, and run svn up on the server (to no effect other than removing the modified flag on the file). Committing stuff to wmf-deployment-something and merging it back is a lot trickier and should ideally be avoided.
Roan Kattouw (Catrope)
On Mon, Jan 11, 2010 at 10:12 PM, Tim Starling tstarling@wikimedia.org wrote:
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 would suggest calling them 1.16wmf-rXXXXX, putting the version number of the original branch point in $wgVersion and the branch name. Also, remove the automatic SVN revision indicator from Special:Version if the wiki isn't running off trunk. That way when we say "Committed as rXXXXX", we can again tell people to wait until the revision given on Special:Version passes that for the feature to be live.
Of course 1.16wmf-rXXXXX will mean rXXXXX plus some possibly large number of extra revisions, but the revision on Special:Version always meant that, and it's still useful info: rXXXXX and all previous revisions are in the branch (plus possibly some later ones).
wikitech-l@lists.wikimedia.org