Many proponents of distributed version control systems (DVCSs) say the biggest advantage is that
anybody can create a branch and begin working on a project. Whereas, for a centralized system (such as
Subversion), the would-be contributor needs to have commit access
before they can contribute.
Let's walk through this.
Obviously, this contributor can grab a tarball, make their change, and send a patch file to the project's mailing list. No commit access is required to do that. Why a DVCS, then? Well... the DVCS simplifies the retrieval and application of the patch (by the project's developers, or third-party users of the project). The contributor also gets use a version control system while developing the patch, which I'll just axiomatically state as a Good Thing.
Okay. So if they don't have commit access, then a DVCS is very handy. What would the scenario be if they
did have commit access? The contributor could develop their change on "trunk" or on a branch. We've already stated this is a would-be contributor -- not one of the regular developers who already has commit access. It really doesn't make sense for this person to modify trunk directly, so let's just say the work is being done on a branch.
So why would this potential contributor
not have commit access? Really? All their work is happening on a branch. It isn't like they're going to mess up the project from over there. They're going to generate some commit emails, sure, but maybe the other developers could then provide pointers, assistance, and feedback
earlier than if the contributor had arrived with a patch, as a fait d'accompli. This is
source control, people. Anything changed can always be reversed. No permanent harm is possible.
So why do potential contributors not receive commit access to a branch, as soon as they ask for it? For social reasons. It certainly isn't technical. Projects have an
us versus
them attitude, and
they don't get to commit to
our repository.
For reference, I'll note that the
Apache Software Foundation provides branches to
Google Summer of Code students. These students arrive with no credentials, they get a branch, and then work on their code over the summer. When they are done, the work can be merged back to trunk, if it is acceptable. It has worked out very well for all involved.
In the Subversion project, we set up branches for developers to try out their ideas. We say these developers have "limited commit access" rather than "full commit". I'll also note that there are no
technical limitations on their commit access. Those developers
could commit to trunk if they tried. But
social restrictions prevent them from doing so. We've never had a problem with rogue developers, since it is so easy to undo any mistakes or intentional harm, and to remove their access.
In this respect, DVCSs are simply a
workaround to social barriers put into place by projects. They do not address the core problem: projects should be
inclusive rather than
exclusive.