We support a number of coding repositories and workflows on Assembla. This article is a high-level overview of the alternatives. Some material about code contribution comes from a previous article Agile next generation: Three ways to go beyond scrum.
Innovation in development relies on changes in the way developers deliver code, which is closely tied to the evolution of code repositories. There are many code management workflows, but most fit into four categories.
Lock: Years ago, developers used to copy a part of the code base to work on, and formally or informally lock it, so that other developers wouldn't work on that part. Assembla subversion still has “lock” operations to support this.
Merge: The next development was merging. Developers could work in parallel on the code, and they could "commit" code whenever it was ready, but if they were committing a file that someone else had also changed, they needed to merge. The next generation of version control systems had better support for this merge process, and largely ignored locking. This commit and merge process enabled faster development because you weren't always waiting for someone else to finish.
However, it created a new problem. If you have enough developers making enough commits, they tend to commit errors or conflicts, and you get broken builds. So, you limit the number of people who can commit, creating a new scaling bottleneck.
A central repository with merging makes it pretty clear what is happening in the team, and makes it relatively easy for everyone to work on the same thing.
All of Assembla's repositories - Subversion, git, and mercurial - help individual users update and merge code while working in parallel. They also support state of the art notifications and code viewing so that you can track what other people are doing.
Pull: Distributed version control systems like git provide a safe place for developers to commit, merge, and test in their own repositories or branches. A technical lead or "maintainer" can then pull the changes, test them, and commit them to a master branch. This pull process allows any developer to work on a new version. It expands the pool of potential contributors and the effectiveness of open source development. However, it depends on the capacity of the maintainer to pull and test code.
Assembla git and hg support this process with branch and "fork" operations to create contributor repositories, and patch requests to bring code back into the master version.
As illustrated in this diagram, there is a lot of pulling and merging required in this process. Each contributor is essentially a maintainer for his own repository or branch. In exchange for this work, you escape the curse of central planning, which is that the central planner is not omniscient, and doesn't know what to do, or creates delays. Just do it!
Review and Accept: If you use a scalable process for reviewing and accepting code, the maintainer will not be a bottleneck. When developers post a changeset, it will go through automated tests, and gather votes from code reviewers. If it passes all tests and gets enough votes, it gets accepted and merged into the master branch. This process is scalable because you can have many people that are authorized to vote and and approve code. With Assembla's Gerrit release, we support this process.
The Gerrit process runs off one central code version, and requires less work from each contributor. This "trunk oriented" workflow builds teamwork by making sure that everyone is working on almost the same thing. We use it, and so does Google.