How are DVCS used in large teams?

Question

I've recently started getting into Git on a personal project, and I can see how a DVCS might benefit us at work (which is a large enterprise software company, currently running Perforce). Feature work in my team for example mostly consists of developers creating their own branches; sometimes these are shared between small teams of developers. I think it would be more efficient in this instance to use a DVCS.

In the more general case, though, I'd be interested to hear from people that use a DVCS at work, in medium to large teams.

1. How do you deal with N-way merges? Is this even a common scenario? Mercurial only supports N-way merges by doing (N-1) 2-way merges (and read that this is the preferred solution in other DVCS), which sounds like a very laborious process for even relatively small N.
2. Do you use a single central authoritative repository, or is it truly P2P?
3. Do developers often push and pull code to and from each other, or does everything go via the central repository?

Answer 1

My team at my previous employer used Git, and it worked well for us. We weren't all that large (maybe 16 or so, with maybe 8 really active committers?), but I have answers to your questions:

1. N-Way merges aren't terribly common. We came up with some conventions about branch naming that allowed us to write scripts that eased the "release engineering" process (I use scare quotes because we didn't have a release engineer), and people would create private feature branches, but we rarely had an issue with merging more than two branches (see the next one).
2. (and #3). We had a central repository on a development server for three reasons: (a) The development machine had a RAID5 (more fault tolerant) and nightly backups (dev workstations were not nightly), (b) production releases were built on the development server, and (c) having a central repository simplified scripting. As a result, N-way merges simply never happened. The closest thing we had to N-way was when someone merged laterally and then merged vertically.

Git was a really great thing for us because of its high degree of flexibility; however, we did have to establish some conventions (branch and tag names, repo locations, scripts, etc, process) or it might have been a little chaotic. Once we got the conventions set up, the flexibility we had was just fantastic.

Update: our conventions basically were thus:

• a directory on our NFS server that housed all central repositories
• we had several projects that shared components, so we broke them out into libraries, essentially, with their own repositories, and the deliverable projects just included them as git submodules.
• there were version strings and release names imposed on us from above, so we just used a variants of those as branch names
• similarly, for tags, they followed the process-dictated release names
• the deliverable projects contained a properties file which I read into the shell scripts, and that allowed me to write a single script to manage the release process for all the projects, even though each one had slight variations on the process - the variations were accounted for in those property files
• I wrote scripts that would rebuild a deliverable package from any tag
• using git allowed us to control access using PAM and/or normal user permissions (ssh, etc)
• There were other conventions that are harder to put in a bulleted list, like when merges should happen. Really, me and another guy were sort of the in-house "git gurus", and we helped everyone figure out how to use branches and when to merge.
• getting people to commit in small chunks and not drop diff-bombs in the master branch was a challenge. One guy dropped about two solid weeks of work into one commit, and we eventually had to unravel it all. A huge waste of time, and frustrating to all.
• informative and detailed comments to go with commits

There were other things that you learn as your team gets experienced and learns to work with each other, but this was enough to get us started.

Update: anyone who follows such things by now already knows about it, but Vincent Dreissen has written a solid and pretty comprehensive (but not exaustive) take on branching and release engineering using Git. I would highly encourage using his process as a starting point because for two reasons:

• lots of teams do it this way or are using some close variant (including Linux, Git, and many other OSS project teams), which means this method has been tested and tweaked to be successful in most circumstances. You are very unlikely to face an issue that hasn't been faced and solved within the constraints of this model.
• because of the foregoing, almost any engineer with Git experience will understand what's going on. You won't have to write detailed documentation about the fundamental nature of your release process; you'll only have to document things specific only to your project or team.