Some replies... 1. Yes. When you have 220 people to herd, some of whom are contractors, there is inevitably a probability of a bad egg or two. Human personalit

Some replies... 1. Yes. When you have 220 people to herd, some of whom are contractors, there is inevitably a probability of a bad egg or two. Human personalities don't scale well from direct experience unfortunately. 2. Will investigate. I think one of our guys tried this and found a number of shortcomings. 5. Until someone doesn't or someone pushes to someone else's repo who then pisses off on holiday (this happens so often on our git projects it's unreal - yes we have a few test git projects on the go as well) 6. Aware of that. However it pushes local branches too which introduces some interesting problems. 7. Yes but on every rev that gets committed? With git people work offline for days at a time and then push to master in one huge chunk and our pre-commit validation would go apeshit (it does a lot of analysis and validation so would result in massive blocking of work if you don't commit early and often). 9. You would have used what you were allowed to ;-) (I tried git-svn and had some problems but they weren't terrible I admit). Regarding backups of workstations, our workstations are disposable. It's not unusual (at least every 9-12 months) for one to get swapped or upgraded overnight with no notice or blow up and turn up with a base image. "meh" and 20 mins and you're back where you started. The mantra is "if it ain't on the fileserver or the SVN, it doesn't exist". Best to checkpoint your shit at the end of the day either by exporting a patch to the fileserver or committing on your feature branch. Nothing else matters really on a workstation and it needs to stay that way. Mainly cat herding issues to be honest. Edit: a final comment... You wouldn't believe how many ways there are to fuck up a software project with 200+ people on it. It's a warzone of competing ideas, personalities and politics. The only way to run it successfully is with an iron fist and strict control. That's probably a large reason why centralised VCS makes sense for some orgs.