Introduction
Fossil uses wiki markup for many things:
- Stand-alone wiki pages.
- Description and comments in bug reports.
- Check-in comments.
- Embedded documentation files whose name ends in "wiki".
- Event descriptions.
The formatting rules for fossil wiki are designed to be simple and intuitive. The idea is that wiki provides paragraph breaks, numbered and bulleted lists, and hyperlinking for simple documents together with a safe subset of HTML for more complex formatting tasks.
Some commentators feel that the use of HTML is a mistake and that fossil should use the markup language of the fill-in-your-favorite wiki engine instead. That approach was considered but was rejected for the following reasons:
- There is no standard wiki markup language. Every wiki engine does it a little differently.
- The wiki markup used by fossil, though limited, is common to most other wiki engines, is intuitive, and is sufficient for 90% of all formatting tasks.
- Where the fossil wiki markup language is insufficient, HTML is used. HTML is a standard language familiar to most programmers so there is nothing new to learn. And, though cumbersome, the HTML does not need to be used very often so is not a burden.
Stand-alone Wiki Pages
Each wiki page has its own revision history which is independent of the sequence of check-ins (check-ins). Wiki pages can branch and merge just like check-ins, though as of this writing (2008-07-29) there is no mechanism in the user interface to support branching and merging. The current implementation of the wiki shows the version of the wiki page that has the most recent timestamp.
In other words, if two users make unrelated changes to the same wiki page on separate repositories and those repositories are synced, the wiki page will fork. The web interface will display whichever edit was checked in last. The other edit can be found in the history. The file format will support merging the branches back together, but there is no mechanism in the user interface (yet) to perform the merge.
Every change to a wiki page is a separate control artifact of type "Wiki Page".
Embedded Documentation
Files in the source tree that use the ".wiki" suffix can be accessed and displayed using special URLs to the fossil server. This allows project documentation to be stored in the source tree and accessed online. (Details are described separately.)
Some projects prefer to store their documentation in wiki. There is nothing wrong with that. But other projects prefer to keep documentation as part of the source tree, so that it is versioned along with the source tree and so that only developers with check-in privileges can change it. Embedded documentation serves this latter purpose. Both forms of documentation use the exact same wiki markup language. Some projects may choose to use both forms of documentation at the same time. Because the same format is used, it is trivial to move a file from wiki to embedded documentation or back again as the project evolves.
Bug-reports and check-in comments
The comments on check-ins and the text in the descriptions of bug reports both use wiki formatting. Exactly the same set of formatting rules apply. There is never a need to learn one formatting language for documentation and a different markup for bugs or for check-in comments.