Importance of client-server protocols [LWN.net]

Importance of client-server protocols

Posted Dec 5, 2004 20:32 UTC (Sun) by robla (subscriber, #424)
Parent article: Looking Past CVS: The Future is Distributed

A lot of version control authors (the creator of arch being among them, IIRC), don't understand the importance of dedicated client-server protocols in creating version control systems. Thus, many "next generation" version control systems make it architecturally impossible to provide secure commit access.

I think distributed development is a cool concept, and can see the allure. However, in large teams of professional developers, a central repository is a fundamental requirement. Here's the biggest reasons:

Central backups
Official repository for nightly/incremental builds
Automated change notification/auditing

All developers who are building code that is to be backed up and built on a regular basis must be given commit access to add new revisions for the nightly builds, while at the same time, be restricted from the ability to "rewrite history", i.e. corrupt or intentially remove older revisions or other audit information.

I've yet to see a next generation, open source solution provide this, other than Subversion, nor has anyone ever provided a credible explanation for why this requirement can be met without a client-server architecture. I'll admit that I haven't yet checked out many of the other systems listed, but I have been conducting an earnest investigation, and I'm fearful that they are like arch in relying on file-level access control, and using the "distributed" mantra as cover for dodging these important requirements.

The sort of power that auditable write access provides is most vividly demonstrated by Wikipedia. As a result of having rigorous auditing of write access, they've proven that it's possible to produce a quality product by giving the whole world write access. There's plenty of vandals, but by having an audit trail and good tools for backing out changes (and blocking vandals), it's possible for the good guys to outpace the bad guys. While I wouldn't recommend the wide open approach for most projects, it provides a good example of why auditable write access isn't just for control freaks.

Does anyone here know which (if any) of the systems mentioned in the story or the comments provide auditable write access, other than Subversion?

Rob

(Log in to post comments)

Importance of client-server protocols

Posted Dec 6, 2004 21:26 UTC (Mon) by kevinbsmith (guest, #4778) [Link]

Your first two requirements do not require a central repository. They merely require that one repository be designated as "official". It would be backed up rigorously, and would be the source for official builds.

Distributed RCS systems offer at least two approaches to solve your write/audit concern. Some packages offer one or the other, and some offer both:

1. Use of a "patch manager" queue process. Developers submit their patches into the queue, and the patches are verified before actually being committed into that repository. The patch manager might require that all patches be signed by an authorized developer, for example.

2. Use of a "pull" model instead of a "push" model. Every developer can publish their own repository, and the official repository can pull changes directly from those sources. Systems like arch, ArX and darcs that allow any http server to host a read-only repository make this especially easy.

Also, with some systems, every patch is signed by the author, so you have a full audit trail available. Note that this audit information acutally follows the patch around, rather than merely providing protection to a single server.