TWiki With Subversion

Subversion is a version-control system designed as a replacement for CVS, started by some of the original authors of CVS. It's under active development, but has now reached a stable version 1.0 after more than four years of work.

This topic discusses the possibility of implementing a TWiki storage backend based on Subversion, and the advantages and disadvantages of such a backend compared to the current mechanism.

Advantages

• "Free" WebDAV view/edit of raw topic texts; probably should be limited to site admin only.
• Entire TWiki w/history stored in a single directory in compressed db4 format.
• Versioning with efficient binary diffing, so versioned attachments start making sense.
• Directory and file move/rename change histories natively supported. Renaming a file does not lose that file's whole history nor is a direct edit of the repository necessary to maintain it.
• Support for arbitrary versioned file metadata, or "properties". Could be used for TWiki metadata, or for emulating features of RCS not available in Subversion.

Disadvantages

• See second point above: since a Subversion store isn't text-based like RCS, it could be harder to recover in the event of problems.
• Subversion's infrastructure is considerably different from RCS's, and a wiki's infrastructure is more conceptually suited to RCS's than Subversion's.
• TWiki uses several RCS features that have no Subversion analogs, so we'll have to emulate these somehow. Discussion of the possibilities for this, below.
  • per-file revision information
  • "replace revision" operation

Implementation Strategy

With respect to the "non-text-based" isuse, at the very least it would be relatively simple to maintain text authoritative snapshots of current versions of each topic with a "working copy" placed next to the repository. This is similar to the current strategy, which interleaves the "repository" and the "working copy" in a single directory tree.

Strategies for implementing RCS-specific features

There are several approaches that have been discussed so far w.r.t. how to emulate the RCS features that TWiki needs but Subversion lacks.

TWiki's storage concept is this: every file has multiple revisions, and the "current" revision can be changed multiple times, only becoming final once another newer revision is created after it. Each revision is numbered, starting at 1 for a new topic and going up from there.

TWiki also supports an obscure, undocumented method for deleting the latest revision of a topic -- this isn't really necessary for proper operation of the wiki, and I think it can safely be stubbed out by a routine that simply returns a failure code. -- WM

Subversion properties

Subversion supports storing arbitrary text key-value metadata along with every file or directory in the repository. We can use this to define where certain revisions of each file are.

The obvious way to do this is to attach a TWiki:revision property to each file that tracks which "revision" that version of the file represents. Whenever TWiki asks for a certain revision, we would have to find the most recent version of the file with the revision property set to that revision number. However, I don't know of any quick way to perform this operation.

Another idea is to have one property for each revision, and in TWiki:rev14 store the repository revision number that contains the latest version of revision 14. However, several operations -- notably mirroring a Subversion repository into another and (IIRC) the text-based dump/load backup method -- can change which number a particular repository revision ends up with. Something like that would completely break this mechanism.

Commit messages

Another simple method is to simply place the "current revision number" in the commit message. Then, to find a certain revision, we simply pull up the commit log and parse upwards until we hit the number we're interested in. Then we request the file as of the repository-wide revision attached to that log entry.

When a "replace current" commit is made, we simply commit a second revision of the file with the same number in the commit message; the next time that revision is requested the new commit will be found before the old, and so will have replaced it as far as TWiki is concerned.

Subversion "copies"

Create a "copy" of each topic for each revision in the repository. After every change, run svn cp <topic>.txt <topic>.txt.rNN before committing. If Store asks for a specific revision, just retrieve it by name. If it just wants the current one, read from the file without a revnum attached.

Because Subversion copies are O(1) (very cheap) operations that remember history, they're acting in this case like something halfway between a branch and a tag. It's not a branch because all changes will get committed first to the "current" version of the file. It's not a tag because which version of the file a particular "copy" points to can change.

Related Topics

• TWikiWithCVS
• GetRidOfRcs
• TWikiWebDavServer
• WebDAV
• RCS
• DistributedTWiki - good summary of following
  • OfflineWiki (ReadOnlyOfflineWiki , ReadWriteOfflineWiki )
  • WikiClusters
  • WebsitePublishing
  • NonWebAccessToWiki
  • MirrorSites
• BetterFileLocking
  • RcsNonStrictLocking
  • PageCheckoutCheckinStrategy proposes changes for TWiki's backend to better accomodate all SCM tools.
• DataAndCodeSeparation
• ModularizationAndCommonTwiky
• TWikiXML

Another Wiki Using Subversion

• Sub Wiki - Wiki for Subversion
• Live Sub Wiki
• Sub Wiki install

Last changed: 18 Mar 2004

Contributors:

WalterMundt
GrantBow
DanDees

Discussion

Note: Older discussion refactored and removed. See Revision 1.11 if you'd like to read it.

-- WalterMundt - 18 Mar 2004

what if we just do away with the revisions numbers, and use closest date&time (with fuzzy matching)? that way we have abstracted ourselves away from an implementation detail of the versioning system.

-- SvenDowideit - 19 Mar 2004

FYI: Distributed Version Control with svk, the author wanted a way to mirror CVS projects into subversion, and wound up adding a lot of other things to make subversion easier too (homepage). The distributed stuff sounds really interesting.

Source Code Management, an essay comparing CVS, Subversion, Arch with a focus on Arch and a smattering of Monotone. A helpful read for a person like myself who isn't all that familiar with the players in this field and what makes them different from each other.

-- MattWilkie - 24 Mar 2004

We've been discussing various VCS's among the CoreTeam, and we've hit upon the resources you pointed to, among others.

Sven's been playing with svk, and it's got a number of very cool features. Note that I'm leery of the distributed-version-control methodology (see this essay for some reasons), but svk is useful for centralized version control too.

However, as a storage backend it makes more sense to use the pure SVN bindings. The two are largely compatible from a repository standpoint, however.

-- WalterMundt - 24 Mar 2004