I think that a documentation system should be a combination of

- reasonably easy to use
- versionable
- able to be used offline
- extractable into an open and transformable format for reuse

Wikis that I've used fail on #2, #3 and #4.

Confluence (as well as other mature wikis) provide #2, and #4 isn't that really to achieve. Most wikis provide some way to version content. It happens that Confluence uses Hibernate and versioned entities for this not a SCM like SVN or Perforce. Confluence wiki- markup could itself be considered that open and transformable format. If you don't like that, then you could always write a transformer into that language which you do like.

#3 is the only one that isn't so easy to resolve out of the box. It is possible however, but is lacking in many ways. For example, you could setup a Confluence standalone on whatever your mobile workstation was, then import/export spaces. Its definitely not ideal, but it is possible.

Perhaps someone will write a bidirectional SVN sync, so that you could update Confluence wiki-markup in SVN, which would then get picked up in Confluence. While this could be done, there are some issues with potential merging conflicts, as the definitive copy of the data is in Confluence (from Confluence's perspective), so if a user offline make several changes, in addition to online users, there would potentially be a window of error.

I realize the clear majority is for Confluence, but these factors should be considered.

There are several... or many (not sure) of us who are aware of these issues. I've been actively looking at resolving some of them and/or finding alternatives which will appease most of the interested parties.

For example, I've got a crude Confluence listener which will persist wiki-markup (w/editor id and comments) to SVN. That gets us closer to a #2 that more people can agree on. Atlassian are cool/reasonable peeps so it might be possible to expose the basic versioning/content mechanism as a plugin to allow us to completly replace that with a SVN impl... but don't hold your breath.

--jason

Reply via email to