A wiki built into a DVCS?

Question

Here we go down the subjective alley ..

Lately, I have been adding a file called 'whiteboard.txt' in some of my repositories. I use Mercurial, but this applies to any DVCS.

The purpose of the text file is to hash out formats, flow, ideas, etc. Given that most distributed version control systems have some sort of web interface, why not denote one directory as a 'wiki' and allow it to be viewed and used as such using something like Wiki Creole markup?

Obviously, only those with commit access could make changes.

My point is, when the code is ready to release, the design wiki and quite a bit of documentation would be done. Why not integrate the two most important collaborative tools into one?

For instance, if I could:

hg --wiki and find the reasoning behind a group of 30 patches as well as their intended direction beyond abbreviated comments in the commit log .. wow :) Any commit could reference a wiki entry, moreover discussions become part of the repository and not a secondary site.

If you like using a DVCS because you can work off line, why would this not make sense?

EDIT:

The whole point of this would be, if 'joe' commits a file, he should be able to set a 'nag' attribute which prompts anyone else changing the file to update a certain wiki page, all done while off line with future merges resolved behind the scenes. After all, it is text, not code and can be treated as a FIFO.

If you can commit off line, you can also update a wiki off line and push your changes later, even in patch format.

The idea is deceptively simple.

Answer 1

Nice idea, but I would keep the wiki in a separate repository.

Somewhat like Bitbucket.org do (when you register a branch, you get two hg repositories, one for the source, and one for the wiki).

Answer 2

I have a couple of suggestions:

• GitHub has an integrated wiki (e.g.). So do many other hosted VCS solutions, such as Google Code.
• Trac is a wiki with very tight VCS bindings and a development-oriented focus.

Answer 3

perhaps http://ikiwiki.info/

A wiki compiler. You can instruct it to store the wiki sources (markdown text files) in a repository (e.g. git, mercurial, subversion). Edits can be done via web, or working copy.

Answer 4

There's a project called Fossil that does exactly this. I haven't used it personally, but it's made by the same person that wrote SQLite, so my guess is it's small and fast. In fact, according to the site, everything is stored inside a small SQLite database, so it should be easy to archive and transport.

Answer 5

See also Hatta. I've been trying unsuccessfully to get it to work, but that's just cause I'm lousy with setting up Python.

Answer 6

To annotate your commits with information about what was done and why is partly the reason why I use an issue tracking system such as Trac. A Trac site (or environment as they call it) can be attached with a version control. You can refer to revisions in version control with 'r', to tickets with the '#' sign, and even wiki pages in Trac.

Now if you were to combine source code and issue tracking together, like Mylyn if you're an Eclipse developer, into your IDE then "magic" starts to happen. I've seen Visual Studio Team System's way of working with issue tracking and version control, but I have to say that I'm more impressed with how Mylyn handles this (since it can also work with issues offline).

Answer 7

Try jscreolewiki, It works off line in a browser, and it's a good idea to store wiki content in a DVCS.

http://jscreolewiki.googlecode.com/svn/trunk/jscreolewiki/index.html