Access control and version control: an over-constrained problem?
For a long time, when it came to sharing code, life was simple: everything went into the w3ccvs repository via ssh; when I commit WWW/People/Connolly/Overview.html the latest version is propagated out to all the web mirrors automatically and everybody can see the results at http://www.w3.org/People/Connolly/. I can also write via HTTP, using Amaya or any command-line tool with PUT support, e.g. curl. The PUT results in a cvs commit, followed by the same mirroring magic.
We have a forms-based system for setting the access control for each file -- access control to the latest version, that is; access to older versions, to logs and the rest of the usual cvs goodies is limited to the few dozen people with access to the w3ccvs repository.
To overcome that limitation, Daniel Veillard set up dev.w3.org which conforms more to the open source norms, providing anonymous read-only CVS access and web-browseable history. There is no http-based access control there, though CVS commit access is managed with ssh.
The downside of dev.w3.org is that it doesn't support web publishing like w3ccvs does. http://dev.w3.org/cvsweb/2001/palmagent/event-test.html is the cvs history of event-test.html, not the page itself. The address that gives the page itself is http://dev.w3.org/cvsweb/~checkout~/2001/palmagent/event-test.html?rev=HEAD&content-type=text/html;%20charset=iso-8859-1. And every GET involves cvs reading the ,v file. And of course, relative links don't work.
For the SWAP project, we use a horrible kludge of both: we commit to w3cvs, and every 15 minutes, dev.w3.org is updated by rsync.
Then I have a personal web site, where I run Zope. That gives me thru-the-web editing with revision history/audit/undo, but at the cost of having the whole site in one big file on the server, and no local goodies like cvs diff. Ugh. I'd like to switch to something else, but I haven't found anything else that talks webdav to iCal out-of-the-box. Plus, I can spare precious little time for sysadmin on my personal site, where there's basically just one user. I was really reluctant to use flickr.com URIs for my photos, but their tools are so much nicer that the alternative is that I basically don't publish photos at all. Plus, the social networking benefits of publishing on flickr are considerable. But that's really a separate point (or is it? hmm).
As I wrote in a January item, we're using svn in DIG. DIG is part of CSAIL, which is a long-time kerberos shop. Public key authentication is so much nicer than shared key. I can use cvs or ssh over ssh to any number of places (mindswap, microformats, ...) with the same public key. But I need separate credentials (and a separte kinit step) for CSAIL. Ah... but it does propagate svn commit to http space in the right way. I think I'll try it ... see data4.
I'd rather use hg, which is peer-to-peer; it's theoretically possible to use svn as an hg peer, but that's slightly beyond the documented state-of-the-art.