Distributed Version Control Systems and the Enterprise - a Good mix? [closed]

Answer 1

To add to the other comments, I would observe that there's no reason you can't have a Corporate Central Repository. Technically it's just another repository, but it's the one you ship production from. I've been using one form or another of VCS for over 30 years and I can say that switching to Mercurial was like a city boy breathing clean country air for the first time.

Answer 2

To me the biggest thing they offer is Speed. They're orders of magnitude faster for the most common operations than centralized source control.

Working disconnected is also a huge plus.

Answer 3

DSCS have a better story (generally) than centralized systems for offline or slow networks. They tend to be faster, which is really noticable for developers (using TDD) who do lots of check-ins.

Centralized systems are somewhat easier to grasp initially and might be a better choice for less experienced developers. DVCSes allow you to create lots of mini-branches and isolate new features while still doing red-gree-refactor checkin on green style of coding. Again this is very powerful but only attractive to fairly savvy development teams.

Having a single central repository for support for exclusive locks makes sense if you deal with files that are not mergable like digital assets and non-text documents (PDFs and Word etc) as it prevents you getting yourself into a mess and manually merging.

I don't think the number of developers or codebase size plays into it that much, both systems have been show to support large source trees and numbers of committers. However for large code bases and projects DVCS gives a lot of flexibility in quickly creating decentralized remote branches. You can do this with centralized systems but you need to be more deliberate about it which is both good and bad.

In short there are some technical aspects to consider but you should also think about the maturity of your team and their current process around SCCS.

Answer 4

Our team used TFS for about 3 years before switching to Mercurial. HG's branch/merge support is so much better than TFS. This is because a DVCS relies on painless merging.

Answer 5

Better synchronization across remote / disconnected locations.

Answer 6

The biggest issue we face with Git in enterprise setting is the lack of path based read-access control. It is inherent in Git's architecture (and I would assume most DVCSs) that if you got read access to repository you get the whole thing. But sometimes a project would require a sparse checkout (i.e. you want to version control sensitive data close to the source, or you want to give third party a selective view of part of the project).

Out of the box, Git provides no permissions - you've got hooks to write your own.

Most of the popular repo managers GithubEnterprise, Gitlab, Bitbucket provide branch based write restrictions. Gitolite allows to be finer grained, providing path (and more) based write restrictions.

The only repo manager I've heard of supporting read access is the Perforce Helix, which reimplements git protocol on top of perforce backend, but I have no hands-on experience with it. It is promising, but I would be concerned how compatible it is with "plain" git.