Ian Bicking: the old part of his blog

Re: Distributed vs. Centralized Version Control

I wish you would have went into this level of detail a month ago or so when we were talking about setting up a public repository for patterns. You're making a ton of sense here. I think you could have a workable model w/ subversion if you could figure out how to:

  1. Self-register or distribute identity. Anonymous write is a non-starter...
  2. Tier access such that newly registered users can create new branches in a sandbox area with full write access but not be able to write outside of their own branches until they were granted higher access.

I wonder if a simple web front end might not help accomplish a lot of this. A form takes a username/password + source branch and create a new "free branch" somewhere and spits that out as a result. This could also have a web/machine interface that you could probably wrap with five lines of bash/curl to have a nice little CLI:

$ svn_share -u username http://example.com/reposhare/trunk 
Hello username, we don't know you. Enter a password for jailed access...
Password: *********
Your branch is http://example.com/repo/username/01/

The command might be best as a wrapper around svn co that would have basic logic for establishing the account and creating one of these "free branches" and then checking it out.

This leads to some problems:

At any rate, I'm interested in hearing more on this if you've thought about implementation at all.

Comment on Distributed vs. Centralized Version Control
by Ryan Tomayko


I was trying to figure out how to set up Apache for this sort of situation in Apache auth -- I haven't had a chance to revisit it since then (sysadmining, blech), but I think there's a special tool for svn permissions which is pretty granuar.

For self-registration it might be sufficient simply to use some simple webapp that manages .htaccess files, maybe with a little something for forgotten passwords and whatnot (a parrallel record of email addresses would have to be kept).

I am worried about security though, especially since Subversion is written in C. C does not encourage confidence in security. Not a big issue when you trust everyone you authorize, but if authorization is opened up...

# Ian Bicking

Wouldn't the Wikepedia model be helpful here as a model for thinking about security? It seems to me that some of security concerns might not be _that_ big a deal since you can just roll back to a previous version if someone pollutes the tree.

# brian

I'm thinking of security like buffer overflows, or people adding gigantic files to the repository which cause the database size to explode (since deleted items remain in the repository database).

# Ian Bicking

One way to do this would be to hook the authentication into something like Bugzilla. We did that at work so that both subversion and bugzilla had the same set of users with just one place to have to deal with them -- the username was a full email address for subversion. This also gives the ability to self-register, reset passwords, etc. A few changes to bugzilla would probably allow patches to point to subversion changes and allow sharing write access to branches.

# David Ward