Anyone use Distributed VCS in a corporate environment?

Question

I'm curious to hear about people's experiences with distributed version control in a corporate environment.

Specifically:

1. Was it difficult to gain adoption?
2. Now that it's in place, is it well liked?
3. What 'model' are you using (hub & spoke? Something else?)
4. Allowing you use hub & spoke, are there any discipline problems with pushing to a central server?
5. I'd like to hear if anyone has non-programmers working within this environment, preferably artists and the like to whom VCS can be a bit daunting. Did it work out for them?

Answer 1

1 - No, because we just told people they had to use it. If you don't have control over your VCS and your staff, you have bigger issues...

2 - Well, going from SVN to Git, I would say about half the developers complained about the added complexity. The other half appreciated the increased power.

3 - We designated one server to be the central repository by convention.

4 - None - I mean if people don't push to the right server, then their work is not considered complete, so cannot be integrated, QAed, etc. If they cannot follow the guidelines for this kind of thing....same as #1 above.

5 - That's a good question. We encourage our non-technical staff to use GUI tools where possible, and that seems to make things much simpler for them. Pretty much all the developers use the command-line, unless they are viewing branch history or some other visual reason.

Answer 2

Do you count IBM Rational (Atria) ClearCase with Multisite as a DVCS?

We've been using it for 15 years now, including 7 years before IBM bought us. It allows us to work fairly effectively across sites in the USA and outside the USA.

For the most part, it works well, largely by keeping out of the way.

Not sure which model applies.

We don't have many non-programmers using it - the ID (Information Development - meaning Tech Pubs) team is the main set of non-programmers who use it.

CC-MS still has a somewhat centralized model - branches are 'mastered' at a particular site, and changes on that branch can only be made in views at the same site. That just means you have to be careful about branching and merging - but the merging is very good (as is the branching).

Answer 3

At the moment I'm playing with the idea of adopting git at work, after I talked it over with some colleagues. They could not imagine it beeing a good idea to use a DCVS. Mostly because they deem the merge-problem as too big. I use git for my own small projects at home and here is how and why I'll use it at work:

• checkout the svn-projects I work at into git
• committing without the need to care about breaking the build (or branching for experiments)
• avoiding the lag of lookups/merges against the central server
• committing the results at the end into the svn-trunk

Incidentally that seems (following the talk Linus gave at Google concerning git) to be a common way of using DCVS at work :)