Why should a business use distributed version control?

Question

It seems that many people read about distributed version control and implicitly understand why it is a good thing for open source development, with many distributed developers all acting independently and in accordance with their own choices instead of mandate from management. But from this impression many people form the idea that DVCS is useful only in an open-source environment; they can't see how it would help an organization that releases a proprietary product and doesn't make its version control system accesible externally, or how it would help a single developer.

What are some benefits a business can see if it chooses to use distributed version control such as git, darcs, or Mercurial instead of centralized version control such as CVS or Subversion?

Answer 1

The argument seems backwards to me.

Given that a centralized revision control system is just one of many use cases of a distributed system, how does applying such a restriction benefit the company?

I know from experience that when a p4 server gets slow or breaks or you get too far away from it or something, everybody who's using it has to stop working.

People like to treat the "plane" argument as a bit of a strawman, but I've been there where it really mattered. On site at an interop event or customer demo where we have to build something now in an environment with limited network support and all that work has to come back and I want to be able to revert when I make mistakes.

The two arguments that I've heard don't ring well to me:

1. can't take all the code and run.
2. locking

Number 1 is just stupid. Maybe it's slightly harder to get the full history (and if I can't, there's not a revision control system anyway), but when it comes to the kind of fear we're talking about here, I can just grab the latest revision and it's just as dangerous.

Number 2 really seems like trying to use the wrong tool for the job. I used to get anti-CVS arguments from RCS users because they really thought you should lock every file every time to prevent two people from, I don't know, working.

Communication is out of band. If you have large, unmergeable files, it's OK to talk about them, I think. IMO, many of the people with this problem don't want a revision control system, but a snapshotting filesystem (zfs, 9fs, Drop Box, etc...).

In general, though, I don't understand why people even ask the "Why should I give my developers tools that are cheaper, faster, more reliable, more robust, and make them more productive?" kinds of questions.

Answer 2

I agree with VonC, but would like to add that (in git at least) it's trivial to make new branches where I can easily work on experimental code or prototypes that I don't necessarily want to share with the rest of the repository's users. This helps keep the central repository clean (if you use one) and I think frees up developers to try things they might not otherwise try in a system where you risk putting experimental code into the central repository.

I've also noticed that working in multiple branches with git is a lot more productive since swapping between branches is quick and I don't have to multiple branches checked out at once in separate directories.