Request for Comment: Multidimensional TWiki

There is an area of TWiki development that, to me, seems like a natural and, yet, has not been explored (as far as I can see). That area involves the change management of all the pages in the TWiki in a unified manner. It seems to me that the ability to "travel back in time" on the TWiki would be very useful from an enterprise's point of view. With this ability, you could easily check the documentation of a company product as of a particularly release or follow the evolution of a product's design documents through time. The obvious next phase to this ability would be to reset the TWiki to a particular time (or label) and then go off in a new direction within the TWiki by branching off in the underlying change control system. Now the TWiki itself can track the development process of company products which can make the development process more integrated with what is being developed. New versions of the company product now become branches on the TWiki tree. Going from one product version to another would still be as simple as following a URL.

Does the above make sense to TWiki people? Is this a capability that TWiki users would want? Does anyone have further use cases for this capability?

-- Contributor: DavidMasterson - 2010-11-13

In the past we had some discussions on a way-back feature where you can browse content as it was at a point in the past. I think that would be a useful feature. The UI needs to be made intuitive and clear enough. For example, there needs to be a prominent indication that you are on a time travel and how to get out of it.

Interesting thought of branching content in TWiki. I am wondering on practical applicability.

-- PeterThoeny - 2010-11-13

Practical applicability would be in the context of product development. A product going through many releases might have multiple releases in the field. If a customer hits a problem with one of the releases, the requirement might be to fix just the problem in that release and put out a special patch to address the problem. In developing the patch, the development team might want to reset the development TWiki (web) to the time/label of the release so that they could be sure that all the documentation in the TWiki applies to that release and not to some feature that was added to a later release. Having a switch to set this in the TWiki helps prevent development mistakes (like a developer fixing a problem that actually applies to a different release).

Naturally, as this capability is added to TWiki, you'll also need enhanced ability to diff two different versions of the TWiki based upon release labels. You may also want to have the ability to set time(s)/label(s) that you want to view in the TWiki on a per-user basis as some developers might be working on the patch while others continue to work on the next release.

This would be a powerful selling point to TWiki!

-- DavidMasterson - 2010-11-13

Wouldn't you accomplish the same thing (with no changes to TWiki) by using any change management system (CVS, GIT, ...) and checking in "snapshots" of the entire TWiki content? No need to wait for TWiki development.

-- RandyKramer - 2010-11-13

In a pinch, perhaps. However, using an external SCM to snapshot the TWiki would mean needing to setup a new TWiki anytime you wanted to rollback to a previous time or your TWiki would need to become read-only while you travel back in time. Using the internal TWiki SCM would (probably) allow you to be more dynamic in your travel in time. For instance, while user A travels back in time, user B could still be working on the latest stuff in the TWiki. Finally, using an external SCM would be a manual operation to create the snapshot while the history is already in the TWiki if you could just get at it.

-- DavidMasterson - 2010-11-17