I haven’t done a study, but Subversion is a very popular Version Control System, but it is centralized. Centralized VCSes have the notion of a “patch” since you can’t share source without submitting it to the central Version Control server. Decentralized version control systems are proving to scale much better and actually be more usable in the process. Git and Mercurial are two of the distributed version control systems that seem to be proving themselves among their customer base. I have experience with Git, and at Headspring, we are considering running a pilot project on it since we have successfully moved one of our sponsored open-source projects onto the system (MvcContrib).
The point of this post isn’t to point to any single product and say “use this product”. It is merely to recognize what I see as a shift toward distributed version control. Because every developer has a cloned repository, the only operations that require a network connection are push and pull (this probably differs a bit). Conceptually, the advantages of distribution of version control is that it is fast, really fast, to show logs, commit, roll back – because you don’t have to wait for the network to do so.
With the distributed workflow, you perform the following steps:
- Clone the remote repository
- Modify some of the source
- Commit your changes locally
- Do some more modifications and commit
- Perhaps roll back some of your modifications
- More modifications and commit
- “Pull” from the remote repository (merge remote changes to your local repository)
- Run your private build to ensure the software is stable
- “Push” changes to the remote repository (now the rest of the team can get your changes)
You still go through this cycle very quickly, but it adds another level of being able to describe discreet changes.
We’ll see where the industry goes with distributed vs. centralized version control systems.