Hello together!
Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ?
So far I did not found anything in this direction ...
If not possible: is this due to data model mismatches or "just" missing man power to have it implemented?
Thanks in advance!
Heiko Nardmann
I don't believe anybody has successfully done this for MediaWiki, and to my knowledge this is would be difficult to impossible. Our backend storage has to implement SQL in some way.
I think I once saw a semi-functional project which could export a MediaWiki database into git. I might be able to find it again if that helps.
There is a Haskell-based wiki which does use git as a backend, called gitit.
http://code.google.com/p/gitit/
On 5/6/11 2:33 PM, Heiko Nardmann wrote:
Hello together!
Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ?
So far I did not found anything in this direction ...
If not possible: is this due to data model mismatches or "just" missing man power to have it implemented?
Thanks in advance!
Heiko Nardmann
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sat, May 7, 2011 at 12:10 AM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
I don't believe anybody has successfully done this for MediaWiki, and to my knowledge this is would be difficult to impossible. Our backend storage has to implement SQL in some way.
What about LDAP? It's used for authentication anyway, and it'd open the way to block users from editing,reading etc. certain namespaces or articles totally fine-grained... simply make a sub-element "userWriteBlock: cn=foobar,dc=en,dc=wikipedia,dc=org" to an article / NS entry you don't want a certain user to be able to edit. Files could also be stored in a LDAP daemon, though this DOES suck for anyone trying to edit the LDAP tree by hand.
Marco
On Fri, May 6, 2011 at 5:33 PM, Heiko Nardmann heiko.nardmann@itechnical.de wrote:
Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ?
Unlikely.
If not possible: is this due to data model mismatches or "just" missing man power to have it implemented?
MediaWiki assumes an SQL database backend, and breaking that assumption would require rewriting MediaWiki. However, certain things are abstracted and can be stored in different ways. Uploaded files are one example. The text of article revisions is also handled separately -- it can currently be stored separately from the rest of the database, and you only need to do primary-key lookups (I think), so I imagine it wouldn't be too hard to write more backends for it. You've got to have *some* kind of SQL RDBMS for the bulk of the data, though, at least SQLite.
VCSes are normally not designed for concurrent writes, or multiple writes per second, so I'd expect scalability of any VCS backend to be nonexistent. But it should theoretically be possible to put article text in a VCS if you wanted to do some coding work, I'd think. I have no idea what you'd gain by doing so, however.
On Sat, May 7, 2011 at 12:20 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
MediaWiki assumes an SQL database backend, and breaking that assumption would require rewriting MediaWiki. However, certain things are abstracted and can be stored in different ways. Uploaded files are one example.
<s>can</s>should
----- Original Message -----
From: "Heiko Nardmann" heiko.nardmann@itechnical.de
Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ?
So far I did not found anything in this direction ...
Github has a wiki based on git as part of the package it supplies to its subscribers. I've been working with it a bit, writing and expanding the doco for the K-9 android email client, and I'm *incredibly* unhappy with it; it violates the Principle of Least Astonishment in so many, many different ways.
Sometimes, the tool Not Invented Here is still the best tool, Dogfood Principle be damned. NASA doesn't design and build their own office/IT PCs.
Cheers, -- jra
On Fri, May 6, 2011 at 3:32 PM, Jay Ashworth jra@baylink.com wrote:
----- Original Message -----
From: "Heiko Nardmann" heiko.nardmann@itechnical.de
Is it possible to have a version control system, e.g. Subversion or Git, as the backend for MediaWiki instead of a DBMS ?
So far I did not found anything in this direction ...
Github has a wiki based on git as part of the package it supplies to its subscribers. I've been working with it a bit, writing and expanding the doco for the K-9 android email client, and I'm *incredibly* unhappy with it; it violates the Principle of Least Astonishment in so many, many different ways.
I think that's more to do with their implementation & UI than the actual storage; git should in fact be a very nice, flexible backend for something like a wiki. I've actually been thinking about ways to use git or git-like storage for a multi-user wiki-like environment, and may end up exploring that in some side projects.
As for MediaWiki itself, it would be a bit awkward to hook an entirely alternate storage & versioning engine in for page revisions as a lot of code assumes being able to work with the revision table -- lots of things fetch data directly from the database which has a single-branch CVS-like versioning model already baked in (each page has a bunch of linear versions on it).
The low-level text storage itself is pluggable and access to text is encapsulated through the Revision class; the 'external storage' system allows an extensible way of storing raw or compressed page text.
But, this has a different level of abstraction from what you'd want for SVN or Git integration. The low-level storage only is given particular blobs of text, without any revision or page context information. You can find out which revisions are 'adjacent' in the versioning system after the fact by going through the page/revision tables later -- this is used to optimize bulk storage by rolling over old individual texts and migrating them to new entries that combine diffing or compression for similar texts.
-- brion
----- Original Message -----
From: "Brion Vibber" brion@pobox.com
On Fri, May 6, 2011 at 3:32 PM, Jay Ashworth jra@baylink.com wrote:
Github has a wiki based on git as part of the package it supplies to its subscribers. I've been working with it a bit, writing and expanding the doco for the K-9 android email client, and I'm *incredibly* unhappy with it; it violates the Principle of Least Astonishment in so many, many different ways.
I think that's more to do with their implementation & UI than the actual storage; git should in fact be a very nice, flexible backend for something like a wiki. I've actually been thinking about ways to use git or git-like storage for a multi-user wiki-like environment, and may end up exploring that in some side projects.
I know. I guess I just felt like beating them up a bit for making me look foolish while trying to help out on a project whose lead developer I'm not a favorite person of in the first place.
Or I'm just a Mediawiki partisan, more likely, cause we've already gone through all the design pain to get to a place where we've got all the important stuff in our code (that Github's doesn't).
One notable feature (which apparently doesn't work the way you'd think) is that the wikitext parser *is selectable on a page by page basis*.
Of course, it's possible to change that on a page that's already got a bunch of text in it, and *no*, it doesn't store a parse tree and give it to you in the format you'd like, as that makes you expect... it just changes the parser for the page, but not the text.
Breaking it.
For everyone.
Baaaad programmers. :-}
Cheers, -- jra
The problem is that we want a CVS-like interface, with per-article versioning. Only a few operations would be cross-article (renaming, moving sections to a different article...) and we don't have a way to express transactions anyway. There's no global status of the code to keep. The articles should be freely modifiable concurrently. Using something like stock git we would end up with almost a branch per article.
wikitech-l@lists.wikimedia.org