How suitable is a DVCS for the corporate environment?

Question

I've been using SVN for some time now, and am pretty happy with how it works (but I can't say I'm an expert, and I haven't really done much with branches and merging). However an opportunity has arisen to put in some new practises on a new team and so I thought I'd take a look at DVCSs to see if it's worth making the jump.

The company I work for is a pretty standard company where we all work in the same location (or sometimes at home) and we want to keep a central store of all code.

My question is: if all you are doing with a DVCS is creating a central hub that everyone pushes their changes to, is there really any benefit to moving to a DVCS and its extra overheads in this sort of environment?

Answer 1

With DVCS's people can maintain their own local branches without making any changes in the central repository, and push their changes to the master repository when they think it's cooked up. Our project is stored in an SVN repository but personally I use git-svn to manage my local changes and find it quite useful, because we are not allowed to submit all the changes immediately(they have to be approved by the integrator first).

Answer 2

It all depends on how you want to work on projects. Distributed environments are great if everybody wants to build on its own branch. I prefer a central repository for my work (in a small team) as it makes the developers think about releasing one version of our product.

In my experience I see a lot of DVCS users who think of their own changes as the ones they don't have to review and these users review the changes of all other developers before merging them in their own tree. I like to see my changes as the change to the core product, so I review these changes before I commit them. As a result we try to keep the product pretty stable during the entire development cycle. Refactoring works OK, as we all update often.

Several DVCS users I know prefer to work on their feature on an independent tree and leave the integration with the central product to the final phase of their development. This works fine if the feature is independent, but I wouldn't like to be the one who has to integrate all the features developed this way with a deadline in sight.

If you integrate often, DVCS's don't differ much from central VCS's, and most DVCS's support a central repository, while more and more central VCS's support several features that where unique to DVCS's before, like offline commit and shelving.

(FYI: Offline commits are planned for Subversion 1.8)