BranchingWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Related to the quest for a ViewPoint like system, it might be interesting to keep in mind the possibility of a wiki in which pages could be forked (or branched) into multiple concurrent versions.

Problems this helps to solve:

Edit conflicts (and high traffic)
Cluttered pages;
- Perhaps it would be easier to refactor a page if you literally split it temporarily into separate factors and then simplified each of those, with each factor represented in a different branch.
- This way multiple people could refactor a cluttered page in a few different ways, and then the community can decide later which way of doing it was best (or, more likely, create a composite).
Moderation schemes
- For instance, if you wanted some changes to be checked over somehow before becoming live, those changes would sit in a branch until being accepted into the main trunk.
- AutonomiWiki is a proposal that builds on this scheme to create autonomous WikiSubcommunities.

Disadvantages:

Some way must be found to merge the pages. In my view, branches of a single page should never become permanent (unless one of the branches is renamed and so becomes a new page). (in the case in which there are different ways to look at the same issue, a system of "facets" is more appropriate than "branches").
Even if merging is made efficient, there will be the temptation to leave separate branches open rather than to bother to merge.
Confusingness.

How to do it?

Software

A CVS or similar backend
- Known wikis which support a CVS or Arch backend (which may be a good starting place for a BranchingWiki):
  - AtisWiki? (see Wiki:AtisWiki)
  - CVWiki (see Wiki:CVWiki)
  - DevWiki? (see Wiki:DevWiki)
  - JSPWiki (partial)
  - ServletBasedWiki? (in development; see Wiki:ServletBasedWiki)
  - PyleWiki?
  - TinyWiki
  - MoinMoin? (http://c2.com/cgi/wiki?WikiMoinMoinReviewZeroFive indicates that it can work with CVS)
  - By extension, any wiki which stores the pages as simple text files and which can deal with the files being changed from the outside, or any wiki with a sufficiently pluggable backend such that a CVS extension would be trivial.

Merging

Gazest[1] is a BranchingWiki that aims to include smart-merge, but development seems to have stalled.

Distributed synchronized Wikis

What about several geo-located wikis, that are coupled by CommunityWiki:RecentNearChanges, CommunityWiki:RecentFarChanges compatible namespaces (via WikiPrefixes), collaborating in parallel, with the opportunity of specialisation (like biological organisms): Wikis that are predominantly

 idea generators, idea elaborators, 
 (trans-)action oriented, reflection oriented 
 building oriented, description oriented
 ..
 StayPoor oriented, WikiNomics oriented

Other

I should note that although I am moderately interested in this for normal wikis as an EditConflict resolution method for high traffic sites (such as a wiki news site on the order of slashdot), I'm also interested in it for CommunityProgrammableWiki.

-- BayleShanks

Note that a CVS based wiki would also allow branches whose origin is past versions of a page. I can't see what good this does, though (outside of the CommunityProgrammableWiki context); I guess this emergent "feature" wouldn't be used much.

Also, according to my understanding of CVS, you can't easily "forget" old VersionHistory, right? So the forgetting part of KeptPages would have to be added as an extra feature (and in the case of CommunityProgrammableWiki, could be subverted). But the WaybackMachine? at InternetArchive? allows subversion of ForgiveAndForget anyway if you really care, so that doesn't bother me.