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

First of all, a DVCS does not prevent a centralized code management: you still can set one repository as the "reference" one, all developers pulling from it.
So the benefice (a side-effect actually) here is a natural backup through data replication, while maintaining a central code base.

But the true benefice comes from inter-projects cross-development: i.e. when you need developments "from the other team, from the other project", in order for your work to go forward: you can easily pull one one their working branch into your repository (by tracking it), without having to wait for them to publish it officially in the central repository.

That means even with repository only replicated internally (within a company), you still get the main advantage of a DVCS, namely the ease of tracking, pulling and merging branches from local and diverse repos, while having a main base where to publish your code for the rest of the development life-cycle.
(every integration, homologation, pre-productions tests would only runs from codes published into that central repository).

One can also see with a DVCS managed that way a natural "cleaning" process (only what is "valid" - at least unit tested for instance - gets to be published into the central repo), with a cleaner history (all the intermediate commits can stay in the topic branches of the local repositories).

Answer 2

I don't see why it's any better for open-source development. Commercial projects have lots of developers working on different things at the same time, too. Does your "mandate from management" tell you which files to edit and when?

Answer 3

One thing I've noticed using Mercurial is that it's changed the way I work, even locally on my workstation. The idea that every copy is a complete, stand-alone repo lends itself to keeping different copies with different work and merging them together or into the "common" repo. That's nice because patch sets for different things stay together, as well as keeping the work itself separate. These things can be done in some manner in traditional systems, but in Mercurial it's natural. Offering more flexibility in organizing workflow has other nice payoffs as well.

Answer 4

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 5

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.

Answer 6

With git there are a number of bridges to traditional central repository based systems.

I find git to be a superior client for svn than svn itself for instance. So if the company insists on using a Central Repository system you can still get the personal benefits of git while still maintaining the central repository.