

Why Perforce is more scalable than Git - yangyang
http://gandolf.homelinux.org/~smhanov/blog/?id=50

======
snprbob86
Centralized systems scale up.

Decentralized systems scale out.

There is a very big difference that must be understood.

I've used Perforce and Team Foundation Server (which is a re-write of Source
Depot which is based on Perforce). Each of these systems handle gigantic
source trees with ease, but at what cost? No, it's not the local history or
branching (as the author points out). The problem has much more to do with the
cultural implications.

Most open source projects can be downloaded, configured, built, and installed
with a series of commands resembling `wget`, `configure`, `make`, and `make
install`. Giant proprietary trees usually grow crazy custom processes with
makeshift tools and lots of domain specific hacks. Giant open source trees
instead develop package managers and powerful overlord processes.

Google provides some excellent tree-wide tools in this vein (`gcheckout`,
`blaze build`, etc). However, acquisitions and constant growth are assaulting
the integrity of their beautiful master tree. Oh, and Google's entire company-
wide tree is only a fraction of the size of Windows, or Office, or DevDiv
(Visual Studio, .NET Platform, Etc). My understanding is that many individual
developers and teams at Google are using Git on their directories until they
need to feed back in to the rest of the company.

What we need is MORE decentralized tools that work better together. We need to
develop tools which, by virtue of their nature, encourage componentization and
separation of concerns. Bug trackers, code review tools, build servers, test
servers, deployment processes, etc. need to support decentralization. GitHub
is a PERFECT example of how to do this: it's a centralized tool but that tool
really is just a giant powerful overlord for a decentralized tool. It gets the
best of both worlds while encouraging a culture of scaling out. Decentralized
tools typically cater to the open source folks, but you need to cater to
enterprise needs (which implies a minimal level of central control) to earn
mass appeal.

Git forces you to have a small tree, so you are forced to build things in
pieces. I think that's a good thing, but people who have big trees now can
never ever get out. It's pretty much impossible because they, by definition,
have too much code.

~~~
durin42
The use of git at Google is (AFAIK, IANAG) limited to checking out the
revisions of a limited portion of the tree. Kind of like using git-svn to
track just part of a repository and managing most of the checkout using bare
svn.

~~~
snprbob86
That sounds about like what I remember from the 20% project fair I attended. I
think it was `git4` which called `g4` (Google's version of `p4`) in much the
same manner as a `git-p4`. The goal was to help out distributed teams, who
were often affected more directly by scheduled Perforce maintenance and
network latency.

~~~
DannoHung
git p4 is okay, but uh... how far along is git4? Is it open? Couldn't find a
project page with a quick google.

~~~
snprbob86
I don't think the project is public. I think it was highly dependent on
internal infrastructure.

------
gcv
Git does not like the use cases the author writes about. Git does not like
gigantic sprawling repositories (Linus mentioned in his Google talk that this
was a problem with importing the KDE tree). Git does not like large binaries
(there is some chatter on the mailing list about somewhat improving the
situation), which makes it tricky to use for, e.g., games. Yes, Git is not
perfect for every group and every use case. News at 11.

Beyond that, the author's snarky comments fall flat until they simply begin to
contradict themselves: "The distributed stuff isn't really asked for, or
needed... Just give me a version control system that [lets me] merge changes
into my coworker's repos, without having to check them in first."

------
brown9-2
The "Perforce at Google" case study that this article links to seems to
discount some of the ideas that Perforce is super-scalable. Things like:

\- "Every command, from any client (e.g., p4v), appears to the server as if it
came from the p4 command line." \- "Each command starts a process on the
server."

Of course, this is probably a use case in the extreme (and it was 2006), but I
think it just goes to show that it doesn't make much sense to make such
absolute statements ("X is more ___ than Y").

------
chrisbolt
See also: <http://news.ycombinator.com/item?id=516276>

------
icefox
I would argue that having every project ever in the same repo isn't a good
thing to have even if Perforce can handle it.

------
theBobMcCormick
Sounds like they're both optimized for very different use cases and very
different definitions of scalability. Good to know.

