Re: moving to a git-backed wiki
- From
- J.H. <warthog19@eaglescrag.net>
- Date
- Feb 3, 2011, 02:24 UTC
- Message-ID
- <4D4A11D7.4040103@eaglescrag.net>
- In-Reply-To
- <4D4929F4.3020805@snarc.org>
On 02/02/2011 01:55 AM, Vincent Hanquez wrote:
Show 7 quoted lines
> On 01/02/11 22:48, J.H. wrote: >> The wiki will almost universally have a "central site" no matter what >> the backend. Personally I see little advantage to having a git backed >> wiki myself. > with git based wiki, you can clone the whole wiki on your local machine, > and read/edit/commit on it locally using standard editor tool (i.e. > $EDITOR). and the history/revision/diff is completely built-in.
That would be fine for things like source code or documentation, but you end up with a single person who would need to merge / push things to a central location, a-la git.wiki.kernel.org. You are now taking something, that is already editable by anyone, and making it only editable by a single person.
You also have a scalability problem. Git is *VERY* memory and i/o intensive. While you basically have a cache of data that is static (the basic pages you are viewing) things like the history, edits, etc can be quite expensive to generate.
Think about a site, we'll use git.wiki.kernel.org, where it's not running on a single machine, but a cluster of machines (how many web infrastructures, including git.wiki.kernel.org run) and now you have a problem of an edit happens and commits on node3, a different conflicting edit happens on node9 and when those try to merge - you get conflicts.
Let me be clear here, I think the idea is interesting, but I think in trying to replace a full wiki it's a horrible idea, particularly since you are pushing a lot of manual work - somewhere, and trying to use git as a nosql database without some sort of locking system.
Just my $0.02 though.
- John 'Warthog9' Hawley