On Wed, 04 Apr 2012 14:33:25 -0700, Jack Phoenix jack@countervandalism.net wrote:
To those who don't know me yet, hi! I'm Jack Phoenix, and I've been a MediaWiki developer since May 2008.
One of the major third-party users of the MediaWiki software is wikiHow ( http://www.wikihow.com/), a free how-to manual. In my opinion, wikiHow rocks! (No, I don't work for wikiHow and I never have.) However, wikiHow has one rather big problem. You can see it on their Special:Version. Yep... the site's running MediaWiki 1.12 (!), which is four years old. In software development, four years is an eternity. However, wikiHow's technical team is rather small and their codebase is full of custom extensions, patches and hacks -- as a result, they don't really have time for gigantic projects, such as upgrading the MediaWiki engine, let alone managing an open source project. Fortunately wikiHow publishes their source code at http://src.wikihow.comand a new dump will be generated each Monday.
Inspired by this, a fellow developer and a friend of mine, Lewis Cawte (User:Lcawte) created a Google Code repository for the project. You can see the project page at http://code.google.com/p/wikihow/ Basically, the goal of this cleanup project is to update, fix, tweak and patch wikiHow extensions and related things created by wikiHow and make them work on the most recent stable release of MediaWiki (which is currently 1.18.1). In addition to that, the project provides a web-based viewer to see diffs between these weekly code releases. Upon a code release, the older source code dump is deleted from src.wikihow.com and there's no way to see what changed between two releases, if you don't have both source code dumps and GNU diff or some other diffing utility available. We hope that in time, when the project is complete, wikiHow.com can switch to this codebase and abandon the one based on MediaWiki 1.12.
Right now we're managing the official code releases like this: *each Monday, when a release has been done, a new folder in tags directory is created (http://code.google.com/p/wikihow/source/detail?r=30), *the diff generated by "diff -ur older_release newest_release" is applied against the newly created tag ( http://code.google.com/p/wikihow/source/detail?r=31), *and eventually these changes are applied against trunk as needed ( http://code.google.com/p/wikihow/source/detail?r=39); right now this is very easy since most extensions haven't been cleaned up, but in time this will take more developer time, as the changes need to reviewed more carefully
We're inviting anyone interested in MediaWiki development, wikiHow or both to join the project! There's /a lot/ of things to do and right now there are only two people working on it (me and Lewis); it's going to take a while for us to fix everything and still something might slip by us, so we're hoping to have more eyeballs on the code.
The code repository is a SVN repo at http://wikihow.googlecode.com/svn/trunk/ and we're very liberal with commit access, just ask one of us for commit rights and you'll get 'em right away! (For those wondering why SVN and why Google Code, the answer is pretty simple: both of us are more familiar with SVN rather than any distributed version control system, and given that the Wikimedia Foundation is phasing out SVN in favour of git, we didn't want to use it to host this project.)
If you have any questions, please don't hesitate to ask!
On behalf of the wikiHow codebase cleanup project, Jack Phoenix & Lewis Cawte
You should really reconsider that decision to rely on svn to keep this project afloat. You don't have to subject yourself to this horrible workflow we have for core. But you should really consider using git. What you are trying to do is precisely the kind of thing that demands a non-linear vcs like git.
"*and eventually these changes are applied against trunk as needed (...); right now this is very easy since most extensions haven't been cleaned up, but in time this will take more developer time, as the changes need to reviewed more carefully" This is precisely what I'm talking about. You are dealing with 2, maybe even three trees all working in parallel. A WikiHow vendor branch, your tree, and maybe a MediaWiki vendor branch. That kind of thing works beautifully by taking one repo, pulling a git repo of WikiHow's code into it tracked as a branch like 'wikihow' or 'vendor'. And potentially pulling the core repo in (depending on how you structure the whole thing) as another branch. You then work committing wikihow's weekly updates as commits to the wikihow branch maintaining a clean tree of wikihow's codebase history. After a bit of setup to create a master branch with whatever you're working on and one commit with a wikihow commit as a parent into master you're ready. Whenever you feel like it you do a git merge from wikihow into your master branch pulling any code updates into your work. Unlike with svn git's GUIs will very helpfully show you the wikihow tree and your master tree. And show you the connections made where you took commits from wikihow and put them into master. And will also show you when there are updates to wikihow that have not been merged into your branch you're working on 1.18 stuff in.
I ran into two articles on git branches and mergies while searching around I might as well post: http://hades.name/blog/2010/01/22/git-your-friend-not-foe-vol-2-branches/ http://codicesoftware.blogspot.com/2011/09/merge-recursive-strategy.html https://en.wikipedia.org/wiki/Merge_%28revision_control%29#Types_of_Merges
The basic premise is that git intelligently works with the whole tree. Even if you're only merging a single change from wikihow it's still useful. Rather than a simple diff and patch a git merge works with a 3 way diff. Meaning you'll likely end up with fewer pointless merge conflicts later on.