On Wed, 04 Apr 2012 14:33:25 -0700, Jack Phoenix
<j...@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.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
