shap@eros-os.org (Jonathan S. Shapiro) wrote on 12.04.00 in <060401bfa42b$dab66a00$c06bf6d1@erosos.org>:
> While DCMS is distributed, the one place where an atomic commit is required
> is branch update. A "branch" is really a variable that names a
> configuration. The problem is that if two commits are allowed to occur in
> parallel on distinct servers, then the sequentiality of branch revisions may
> be violated.
Hmm. We really have two different things here: a branch as in a sequence of changes, and a branchname as in something that identifies one particular such line.
I'd say that a commit of changes should probably *always* create (in RCS terms) a new branch - that is a collision-free operation - and thereafter, one can decide upon the name, including if this is to be considered the new top of the previous branch. (This is made much easier by the "everything is a branch" model.)
As to encrypting the repository, I'm not sure too much detail here is useful.
(1) If the repository owner is forbidden from seeing the contents, the server cannot be allowed to decrypt the contents (because otherwise, the owner can do so, too). That means the server cannot understand deltas, which means it's reduced to being a file server.
(2) Similar arguments apply to being secure from root. Really, if you cannot trust root, you might as well give up; it's possible to get secure against root, but it needs OS kernel level measures, not application level ones.
(3) If you're exporting a repository to someone else who may only read parts, why on earth do you export the parts he may not read in the first place? Data that's not there doesn't need to be encrypted. And given that you won't give him the key, the readable part of the repository must be usable without the rest anyway.
(4) What's left is transport security. I think we pretty much agree that that part is already solved - PGP encrypted mail, SSL tunnels, whatever.
MfG Kai