Version Control Applied To Wiki

http://ikiwiki.info/features/ uses svn/git

QuickDiff, which Wiki provides, is about the simplest kind of version control: the ability to check the differences from the previous version.

The TwikiClone keeps a long sequence of revs available via RCS. It includes a diff feature. This may be all you need; if you can see the complete evolution of a page you have a really open system - a fully open system would let you start alternate evolutions at any point (TimeTravel in the MultiVerse).

CvWiki actually does give you a time-machine - you can look at any version of any page and then follow links to check out the entire wiki as it was at that point in time. But in practice this is far more problematic than it is useful, because it runs counter to WhyWikiWorks. The diff functionality is what's wanted; an extension of QuickDiff to keep multiple diffs like TwikiClone, but not to render the old pages easily nor start alternate evolutions - at least not without starting a whole separate wiki - seems like a good idea.

I think that revision control is difficult to present simply to users. Can anyone here who uses a wiki with version control recall a time when they really needed revision control. I'm wondering whether people really need this feature, and if they do, exactly what for? --

Somebody obliterated WysiwygWiki around about 7 April 2000. By the time I discovered it, it was lost from the diff. If I could have gotten to it easily, I would have resurrected it. On the other hand, full management for branching and merging seems like overkill. -- CurtisBartley

The WysiwygWiki obliteration points to an interesting issue-when an author includes a WikiWord in a discussion, it is with the belief that the current content of that page is useful to the discussion. If the content of the linked page changes it can potentially weaken or remove the intended meaning. -- JimBrosnan See also the paper about aging links at http://www.sts.tu-harburg.de/papers/STS-Pub-2000.html#NSSM00. -- AxelWienberg?

WikiGS, a wiki server written in VisualWorks that uses GemStone for persistence, keeps a version history of each page. -- RandyStafford

SoftWiki uses a database back-end which records each modification in a log. It's possible to write a script inside SoftWiki that can access that log and follow the revision history of an object; however, the log is really designed for recovery from abuse or accidents that cause widespread damage to the database, and not retrieving the individual modifications to one object inside that database. This is partly because the security consultant inside me refuses to allow anything to be truly public-writable, and partly because I want an environment that forces me to have an automatic backup copy of every change to programs and data, no matter how insignificant, with some kind of auditable changelog, even if it is cumbersome. Where it's important for the revision history of an object to be accessible and meaningful to a user, the revision history (and the user interface to present it) will be implemented in some application-specific way inside the SoftWiki object in question. -- ZygoBlaxell

From WikiEssence:

It occurred to DavidLaurance that saving a change to a Wiki page could be implemented by checking the page into a source control system.

I'm thinking of a system where the source to all the pages are under SCCS or RCS or Clear Case or something, and the links are files (already expanded from Wiki to HTML). -- PaulChisholm

I'd considered (when working on my clone) using RCS as the storage mechanism, to provide history, but didn't come up with a good enough interface to justify it. (Also the locking is a bit tricky - but the CVS approach is probably good enough for that.) Simply adding change bars of some sort would make following RecentChanges easier. -- MarkEichin

I've just finished implementing AtisWiki (a WikiWikiClone) here at work, which we are going to use as a simple KnowledgeBase?. It has a (very flaky) CVS backend, which I de-flaked to some degree because my manager insisted that we keep versions in CVS. My work is thus GPL, so let me know if you want a copy... -- RobertEikel

Version control defeats the forgive and forget principle of Wiki. For other wikis that would like something in between versioning and forgetfulness, there is http://usemod.com/cgi-bin/mb.pl?KeptPages. It still permits flamewars to continue with a couple weeks worth of history (bad), but it prevents even the most ardent vandalism and yet continues to forget mistakes from the past (good).

I (AndyGlew) am considering tightly integrating a wiki with CVS, or a CVS web client. In fact, my friend MikeHaertel? goes further - he suggests basing a wiki on a CVS web client. Or other version control web clients.

Reason: I would like to use the wiki for a large part of the project documentation. The project is one of several related projects that will share a source code base. These several projects already use CVS to share source code; I would like the wiki database to be one (or several) subdirectories in that source code tree.

E.g. /proj/project[123]/{src,doc/wiki}

Now: sharing source code between projects is good, but most people who have worked on large projects know that eventually you will branch and diverge, even if only for a short time. E.g. a while before FirstCustomerShip? (actually, TapeOut?) a project will go into FreezeMode? or ECO mode: it will place itself on a branch separate from the other projects, who are not so close to FirstCustomerShip?. It will not automatically accept updates to the shared code from the other projects, but will scrutinize them. And so on. Eventually, after FirstCustomerShip?, if the project is ongoing it will unfreeze, and move back to the main branch for the shared code base.

OK, that description applies to code. It also applies to documentation: the documentation describing a tool sometimes is version specific. Instead of describing all versions, sometimes the latest view overrides the others. In which case, the documentation needs to branch just like the source code base. And CVS is our branching tool of choice.

What does this have to do with wiki?

Well, I want the documentation to live in directories like /CVS/proj/project[123]/{src,doc/wiki}, under CVS control.

Given a directory like ~YOU/proj/project1/doc/wiki, a standalone wiki browser, like Emacs wiki mode, can browse the documentation. Or, ideally, a web browser could be directed to it using file URLs. (This may require the wiki to cache the generated HTML.) So, a developer can always look at his current wiki documentation.

Or, as many projects do, a reference checked out view of the documents may live in /proj/project1/doc/wiki. A conventional wiki server may provide access to that.

If the wiki is fully shared, /proj/project123-shared/doc/wiki will always provide access to the latest view.

But if projects are branched, /proj/project1/doc/wiki will allow edits to be done on the branch.

Does this go against WhyWikiWorks? Maybe... but it is an attempt to apply wiki to a broader scope of problem.

-- AndyGlew

The SubVersion guys also have SubWiki: a wiki that uses subversion to store all content. http://subwiki.tigris.org/

Most of the time the wiki data is saved in wiki text format, and then converted to html (or whatever else), when needed. If you use subversion with apache, you can browse/view the repository directly from your web browser. This would be my proposal to a subversion wiki. When you save the wiki data, it at that point creates the html and then submits both the html and the wikidata to the repository. Then when viewing the wiki, you can be reading the pages straight out of the subversion repository.