Paul Hammant's Blog: Tools with Proprietary Source Control? Be Careful.
Too many tools with too many forced source/version control choices. When deploying an application that manages human readable pages somehow, look under the hood and consider how important it is for that content to participate in the corporate choice of source control.
Development Documentation
If you're using a wiki* or similar for project documentation, you have doubtless seen a increase in the willingness of developers to help write it. If your previous technology was Stylebook/Docbook then you are probably very pleased at the productivity kick. Be aware of two things though.
- The technology probable does not support the branch concept that your source control does. When you branch code (live versus development head), you probably don't want a single set of documentation. Consequentially, you might want to merge documentation across branches.
- The content could well be stored in some opaque database somewhere, that hinders a viewing it as conceptual source
Content Management
[ Joe has a forthcoming blog article on this, that's dear to my heart ]
Likewise it is important for content from a user-facing content management system to be version controlled. Commercial CMS systems nearly always have something built in. Usually this is backed by a workflow feature. It is doubtless that these are features that sell well, but it is not so clear whether the needs of the IT department are as well served. The IT department needs to look after all applications and all data over multiple years. With proprietary version control for these applications, the data is nearly always obscure.
"Joined up" source control
What would be nice is tools that manage content or simple project documentation, join in with a corporate choice of source control. If delivered, this might allow rudimentary offline editing.
* Super Wikis
After using Confluence in a couple of places for a few months now, I must say I'm impressed. My only wish is that it also wrote pages to the source control system of my choice. Mike Cannon Brookes told me that source control packages are not good enough to store the indexing information that Confluence needs, but I can't help feel that there is a dual track solution for it. Perhaps the DB that stores index information could be rebuilt from the static/versioned files under source control. Confluence, it is important to point out, supports the notion of XML export. There are many possibilities for the automatic archiving of data from this API, or the trigged generation of something, that could interoperate with source control.
Vincent Massol talks of MoinMoin storing its pages in XML form already. He suggests that it could be the hook for some CVS binding.
There are already some wikis that use CVS as a back end. One is CvWiki.
NNTP & http://c2.com/cgi/wiki
Last year Aslak and I (no, not all blog entries I make feature Aslak) chatted to Ward Cunningham about Ward's http://c2.com/cgi/wiki storing pages in NNTP. The idea being that a federation of NNTP servers could guarantee long lived pages. Threading would be interesting as individuals made changes to pages that took them in different directions (the concept of lock would be missing). Sure it is different to source control (the reason for this blog posting), but it is quite an alluring idea. Especially given it leverages an underused protocol.