I received some well deserved criticism on my weak choice of just using git as an RCS repository. So this is about scaling up operations. Note: I am not an expert on build and deploy systems.
At small levels of team contribution, when there is 1 product and very little branching and merging, git alone will completely suffice. It will support the team's needs and will deliver the first round of product. However, when any of the following happens to an organization, the code repository must be scaled:
- Team structure requires more than one team
- Team structure requires more than one complete stand alone product
- Introduce more complex promotion chains than dev - qa - live
- Multiple products are live and need to be branched
- Branching and merging in changes is a daily task
- Git can no longer handle volume of check-ins
At this point yes, something more industrial that git must be introduced to the information technology architecture of a company. I recommend Perforce over Subversion just because of a decade of experience with the tool*. Perforce has solid support for repository mirroring, repository proxies, and building distributed repositories for very large projects. Here is a complete manual on how to do this exact thing for those interested in building a distributed code repository.
Facebook helmed a neat trick now completely supported by Perforce that employs git to Perforce bridges and allows teams to keep on their local git repos and use all their git tools to focus on their piece of the overall product while code on check-in goes off to the main repo to head through the promotion chains and QA checks before staged delivery to live. If I was running a company and needed to transition from git to Perforce, I would employ Perforce Git Fusion to bridge from the smaller, more developer-friendly solution to the big industrial beast on the back end.
Here's a little diagram I whipped up in draw.io in five minutes to illustrate the idea.
If I was going to deploy a new build of an operating system, or Facebook, or Twitter, here is how I would scale up operations - roughly, in an image drawn in less than 5 minutes.
Go ahead and read the above document on distributed Perforce to get what it takes to architect and deploy a super huge repository. Project Butterfly will continue to use git for the time being.
- Despite 10 years with Perforce I still cannot perform a merge despite carefully crafting python scripts around p4 to do it for me. It's remarkable.