On 07/09/2007, brion@svn.wikimedia.org brion@svn.wikimedia.org wrote:
Revision: 25635 Author: brion Date: 2007-09-07 13:30:28 +0000 (Fri, 07 Sep 2007)
Log Message:
Revert 25602 and 25604 schema changes for now. Please don't commit schema changes to trunk until you've cleared them with me and Tim -- remember trunk is meant to be ready-to-run live at all times. They force operational work before we can update the software again, and it's a big pain in the ass to deal with them unexpectedly.
Does this mean you and Tim will actually be available to review/clear things? You've both previously had a high workload, which meant that absolutely nothing could get done.
Rob Church
Rob Church wrote:
Revert 25602 and 25604 schema changes for now. Please don't commit schema changes to trunk until you've cleared them with me and Tim -- remember trunk is meant to be ready-to-run live at all times. They force operational work before we can update the software again, and it's a big pain in the ass to deal with them unexpectedly.
Does this mean you and Tim will actually be available to review/clear things? You've both previously had a high workload, which meant that absolutely nothing could get done.
I review and sync every morning workday, unless there's a serious problem going on.
One of the biggest things that fucks with that schedule is schema changes, since that means that nothing can go live until the schema updates are in place, which sometimes takes a while since we have to work it in at low-load periods and have to do it in at least two separate batches (slaves, switch master, old masters).
An example recently was the huge rash of schema changes that went in shortly before Wikimania -- that lead to long delays, then we were all away for a week and a half, then more long delays until we were able to get it caught back up.
So please, don't go tossing in unexpected schema changes -- that backs up the whole machine.
Planned schema changes should be, well, planned a little better. ;)
-- brion vibber (brion @ wikimedia.org)
On 07/09/2007, Platonides Platonides@gmail.com wrote:
And what makes schema changes, well-planned? Now it's not wikimania time :)
The usual procedure is to place the code plus schema change plus updaters in a branch and inform Brion. In theory, he'll review the branch and merge it when the system administration team has a proper update plan; often, several large bits will be lurking around in branches for some time, to allow batching up the bigger updates.
In practice, this doesn't happen often enough.
Rob Church
Hi!
In practice, this doesn't happen often enough.
In practice people slip in reindexing of our largest tables ;-)
Rob Church wrote:
Does this mean you and Tim will actually be available to review/clear things? You've both previously had a high workload, which meant that absolutely nothing could get done.
That of course reminds me that we need to do a better job of reviewing things that haven't been committed yet. :)
Which brings to mind that there's some interest in distributed version control systems, which should be better for maintaining and publishing individual work branches than SVN.
SVN's good at making release branches, but performing multiple merges like one needs to do on a work branch is a big hassle, and notoriously slow. I know some people are really excited about git, though there are a number of others popular ones out there.
Having something that's fairly usable on Linux, Windows, and Mac OS X is a pretty strong requirement for us to start poking in that direction.
-- brion vibber (brion @ wikimedia.org)
Hi!
Which brings to mind that there's some interest in distributed version control systems, which should be better for maintaining and publishing individual work branches than SVN.
Individual work branches always get lag and merge jam problems, that need quite some attention to resolve.
SVN's good at making release branches, but performing multiple merges like one needs to do on a work branch is a big hassle, and notoriously slow. I know some people are really excited about git, though there are a number of others popular ones out there.
People are also excited about Bazaar
Having something that's fairly usable on Linux, Windows, and Mac OS X is a pretty strong requirement for us to start poking in that direction.
There's even VisualStudio plugin for Bazaar! :)
Brion Vibber wrote:
Which brings to mind that there's some interest in distributed version control systems, which should be better for maintaining and publishing individual work branches than SVN.
Evan Prodromou's gotten me hooked on darcs.
-m
On 9/9/07, Mark Jaroski mark@geekhive.net wrote:
Brion Vibber wrote:
Which brings to mind that there's some interest in distributed version control systems, which should be better for maintaining and publishing individual work branches than SVN.
Evan Prodromou's gotten me hooked on darcs.
Not that my opinion matters on this subject.. but I'm also a fond of darcs. I use it on some other projects. Other than initial sync taking a while to grab all the patches it's pretty spiffy.
Which brings to mind that there's some interest in distributed version control systems, which should be better for maintaining and publishing individual work branches than SVN.
SVN's good at making release branches, but performing multiple merges like one needs to do on a work branch is a big hassle, and notoriously slow. I know some people are really excited about git, though there are a number of others popular ones out there.
Git could be interesting, although in practical terms the cross-platform-ness doesn't look like it's there yet (see section below).
Background info on git, if it helps anyone else:
Git <--> SVN crash course: http://git.or.cz/course/svn.html
70 minute video of Torvalds talking about git (yes, I know 70 mins is a long time, but he explains the distributed development idea quite well between roughly 13:00 and 30:00) : http://www.youtube.com/watch?v=4XpnKHJAok8
Getting started with git: http://lwn.net/Articles/245678/
Advantages: * No more worries about who has commit access * No mucking about with SSH keys (?) * No single point of failure (?) * Easier merging of branches, with encourages more experimentation and collaboration with branches. I'm not totally convinced that branches & merges work especially well in MediaWiki's SVN (e.g. most commonly, branches tend to be one person working on a branch, making their changes in public instead of in private, and then most often that branch dies a slow death, but very occasionally the changes get merged back, which as a practical consequence I suspect means most people end up making changes in the main tree rather than working in branches).
Questions: * Would we get emailed logs of the commits to the "main" repository? (I'm defining "main" as the code that runs on the cluster, and which gets used for the releases) * What happens with the extensions? If the extension developers have the latest version in their trees, do users of those extensions need to go and grab them from each author of those extensions? Or does the "main" repository maintainer have to pull from the extension writers every time they update their extension? Or can there be a redirect that's transparent to the user that fetches that extension from a different tree?
Having something that's fairly usable on Linux, Windows, and Mac OS X is a pretty strong requirement for us to start poking in that direction.
And it looks like this would be the biggest problem with git : * On OSX, looks like it has to be compiled (yuck) : http://www.dekorte.com/blog/blog.cgi?do=item&id=2539 * And on Windows, it looks like it's being ported currently: http://en.wikipedia.org/wiki/Git_(software)#Portability * And of course it works fine on Linux, surprise surprise.
-- All the best, Nick.
On 20/09/2007, Nick Jenkins nickpj@gmail.com wrote:
Git could be interesting, although in practical terms the cross-platform-ness doesn't look like it's there yet (see section below).
Mozilla adopted Mercurial rather than Git for this reason. Torvalds says in the Google video you mention that if you're not going to go for Git, go for Mercurial.
x.org also uses Git very successfully, and it matches their development model (ten or twenty core hackers working by consensus).
- d.
On 20/09/2007, David Gerard dgerard@gmail.com wrote:
On 20/09/2007, Nick Jenkins nickpj@gmail.com wrote:
Git could be interesting, although in practical terms the cross-platform-ness doesn't look like it's there yet (see section below).
Mozilla adopted Mercurial rather than Git for this reason. Torvalds says in the Google video you mention that if you're not going to go for Git, go for Mercurial.
Oh, and Ubuntu uses (and develops) Bazaar for the same sort of reasons. Mark Shuttleworth talks about version control systems here:
http://www.markshuttleworth.com/archives/123 http://www.markshuttleworth.com/archives/124 http://www.markshuttleworth.com/archives/125 http://www.markshuttleworth.com/archives/126
- d.
wikitech-l@lists.wikimedia.org