FAQ

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. :)
	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. :)