The Carom Repository is this website itself. What? Yes!
The soley fact, that the HTML files were stored in a Subversion repository, were pretty boring, if they then were uploaded to the server by ordinary FTP (as you might have expected).
It gets interesting with the matter, that the web server homes not only the Subversion server (means the repositories as usual), but also a subversion client. This client regularly updates an ordinary workspace of the Carom Repository. And that workspace serves the HTTP server as it's document folder.
Such configuration is certainly a case of Subversion abuse. Subversion was created to serve humans, not servers. You can recognize Subversion as a really great software by the fact, that it is useful for many more purposes than it's developers ever imagined.
The Carom configuration works, it is convenient, it is useful. Only, one must watch out not to tangle up in the multiplicity of possibilites. It allows e.g. for about the following two way scenario:
Oh, in above diagram, we forgot some arrows: The team members, as web developers, may have webservers running on their local machines as well (http://localhost). So they can locally edit the pages not only with notepad or whatever, but via the CMS/Wiki as well (Edit-Point-Static), while the same time debugging that.
The exact working may look like a logic puzzle, if you are new to the idea. You have to understand Subversion and webservers, thoroughly, to recognize the possibilities and the simplicity of the configuration.
Don't forget to configure the webserver not to deliver the hidden .svn folders in the workspace. For an Apache, this is done by the following lines in the config file:
Deny from all
Why did we call this configuration 'Carom'? Carom is the billard with three balls. In a way, carom depicts technical aspects of such configuration, e.g.: