What are the advantages and disadvantages of distributed revision control systems?
If you have any experience with distributed systems like Git, Mercurial, Plastic SCM, etc. please share your experience. Tell us what worked well and where problems arose.
I'm particularly interested to hear about the use of distributed systems in traditional, commercial, non-open source projects but answers about other uses are also welcome.
I've not tried other distributed systems so can't comment on them. But one thing that annoys me about Git is theres no way to only clone part of the repository. Last I checked, it also lacks things similar to svn:externals. I find svn externals are often used within companies for checking out libraries from other repositories etc.
Yeah, checkout the stackoverflow question for this. If you want any more information about how Git compares to other revision control systems, there is a nice informative site for that: Why Is Git Better Than X?
The question sebasgo is pointing to really has a lot of good answers, but let me tell you my personal experience anyway. I work with a handful of other people scattered all over the U.S. doing what is essentially private consulting work. Clients vary in size, but our team is small, and we work fairly fast. The code is commercial but owned by the clients when we are done.
We use Mercurial, but the specific tool is less important than the general workflow of using distributed version control as opposed to centralized. In my experience there a two big advantages to productivity that I no longer want to work without:
Beyond those effects, which apply to all my projects, work-related and not, one benefit specific to our particular arrangement, which relates to your question about commercial use and which was unexpected came up: the client can actually work on the code. They can take a snapshot, make local changes, and either send us back fixes or keep the tweaked code for a particular purpose. This is of great help in keeping them involved, in not getting too far out of sync with what they want, and in allowing them to tweak things without breaking anything (we don't merge in their changes unless they are ready -- same rules we apply for ourselves.)
We don't have a lot of complaints. It takes some getting used to, though the command set of Mercurial is close enough to Subversion (which we used to use) that we've not had a lot of trouble. Even the occasional nastiness, like accidentally checking in binaries or files that shouldn't be checked in, we can get around because we can re-create a repository without those changes, and replace our main one if we need to. This doesn't scale to a large group of people well, but works quite well for a small 3-4 person team.
The one negative I can think of that's actually a problem, is a side effect of being able to branch easily: you can have enough pending work that you lose track of it. This is a little akin to having many drafts of a written document: pass enough copies around and you don't remember which copy had the changes you want. That's not directly a flaw of the tool, and if anything it makes it easier to bring back together disparate work than tools less capable at merging would be. But it is a hazard. The only way I know of to manage it is to be disciplined about writing useful commit logs, useful branch descriptions, and not trying to keep too many open tasks at once. In other words even a very nice workflow is still a workflow and needs attention or it gets out of hand.
I have particular issues with Mercurial (I really want named branch support to be just a little bit easier) and with Git (I really want the command set to be more intuitive, even now), but they are complaints about corner issues that come with great familiarity. They wouldn't even be possible if these tools hadn't pushed the envelope of what I thought a VCS could do far beyond what I knew before I started using them.