Permalink
Cannot retrieve contributors at this time
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
levitation/FAQ
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
163 lines (102 sloc)
6.52 KB
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
What’s the project’s current status? | |
------------------------------------ | |
Have a look a the “Things that work” section in the README. | |
If you’re interested in how active the project is, check the commit history on | |
http://github.com/scy/levitation/ | |
So, you’re running MediaWiki with Git as backend? | |
------------------------------------------------- | |
No. Currently, Levitation has nothing to do with _running_ MediaWiki at all. I | |
seriously doubt it is worth the effort to adapt MediaWiki for a Git backend. | |
Instead, a new frontend should be developed. | |
Okay, so you’re planning to fork Wikipedia? | |
------------------------------------------- | |
Me? Probably not. But I know some guys who might be interested in doing it. And | |
since I think that yet another centralistic Wikipedia is not the solution, I’m | |
experimenting in a different direction. Namely, a distributed Wikipedia. | |
But with Git, won’t every contributor need gigabytes of history? | |
---------------------------------------------------------------- | |
First, if you haven’t heard about “git clone --depth” yet, have a look at it. | |
Second, my vision is to have 5 to 20 “Wikipedias” per language that focus on | |
different aspects and have different policies. These would be hosted by someone | |
having enough resources to do that, and editing articles would be done via a | |
web interface as it is now. | |
The difference to today is, that the Wikipedias can easily transfer content | |
between each other, including history and using Git’s powerful merging | |
capabilities. Additionally, everyone who wants to clone the whole Wikipedia can | |
do it, with full history, and without waiting for a monthly dump. Instead, | |
pulling from Wikipedia gives you the content as it was at that second. | |
Also, Git developers are currently working on the possibility to retrieve just | |
parts of the repository. | |
Wouldn’t it be better to split the data into several repositories? | |
------------------------------------------------------------------ | |
I can’t think of a good way to do that. Where do you draw the line? | |
Most people suggest “one repo per article”. That’s probably the best “line” | |
there is, but how would you then move/rename/merge articles without losing | |
history? | |
Currently, this project is about mapping a MediaWiki history to a Git history | |
while losing as litte information as possible. As soon as that works, we could | |
think about using git-filter-branch or something like that to split it into | |
saner chunks. | |
Would Levitation allow to incrementally import changes made in the current | |
centralistic Wikipedia into one’s local Git clone? | |
-------------------------------------------------------------------------- | |
I think so. There are some possible issues though. | |
If, for example, you would update only one article’s history and then another | |
one’s, history would be in the wrong order and need to be rewritten. Git can do | |
that easily, but the incremental importing tool would have to consider that. | |
Another problem could be that articles you have in your local clone might get | |
deleted upstream. If they are, they no longer show up in dumps _at_all_. | |
Would Levitation allow it to make changes to the local clone and maintain these | |
changes even when importing new stuff from the current centralistic Wikipedia? | |
------------------------------------------------------------------------------- | |
Yes, that’s something that happens all the time in distributed development. | |
Keep the upstream Wikipedia in one branch, your changes in another, and | |
frequently rebase or merge. With things like git-rerere, you can minimize the | |
amount of manual merging conflicts. | |
Would Levitation allow it to make changes to the local clone and push them back | |
to the current centralistic Wikipedia? | |
------------------------------------------------------------------------------- | |
Absolutely, just like git-svn does. Nobody has written that code yet, and I | |
doubt that _I_ will do it, but it should be pretty straightforward. | |
It looks to me as if importing gets slower and slower the more recent the | |
commits become, right? | |
------------------------------------------------------------------------- | |
Maybe a bit (because the trees get larger), but actually not as much as you | |
probably think. Levitation shows you the date in history while it writes the | |
commits, and indeed the time it takes to finish one day is apparently | |
increasing. However, for most Wikipedias, the number of commits per day is | |
constantly increasing, so there’s simply more work to do per day. | |
Why are you doing this anyway? | |
------------------------------ | |
Because I love Git and the development model DVCSs allow, because I’m fed up | |
with de.wikipedia’s attitudes on policy and because I think using Git is one of | |
the better solutions. I would hate it if other people developed another | |
software that’s essentially as flawed as the current Wikipedia model. | |
Me too, how can I help or say “thank you”? | |
------------------------------------------ | |
If you’re looking for the “donate” button: http://pledgie.com/campaigns/6916/ | |
Writing, improving and debugging Levitation is a considerable amount of work. | |
Unpaid work, and I’m a pretty broke student. Your donations will help pay | |
external hard drives to import larger Wikipedias, and basic stuff like paying | |
the rent. | |
If you don’t want to give money, you have plenty of other options: | |
Play around with it and tell me about your experience. | |
If you’re good at Python, rewrite some of my code to be less ugly. One commit | |
per change please, I’m a control freak. | |
If you’re a Git guru, I’d love some hints about how to make the resulting repo | |
smaller and improve overall performance. If you know a Git guru, ask him. | |
If you own a powerful box, import a large wiki and get in touch with me, I’m | |
interested in size and performance. | |
Implement some of the “Things that are still missing” (see README). Please ask | |
me in advance before doing larger changes to avoid your patch getting rejected. | |
I have invested about a week of work in this tool, any material gratification | |
would be greatly appreciated. Have a look at http://scytale.name/wish/, which | |
is continously updated. I also like amazon.de gift certificates. :) | |
If you, like me, don’t have that much money to spend it on other people, | |
writing patches and spreading the word about Levitation is an option as well. | |
So, write blog posts or talk to people on Git and Wikipedia mailing lists | |
about the project. | |
I have a question that’s not answered here. | |
------------------------------------------- | |
Check http://scytale.name/contact/ or send me a patch to this FAQ containing | |
your question. :) |