
Still All on One Server: Perforce at Scale (2011) [pdf] - guessmyname
http://info.perforce.com/rs/perforce/images/GoogleWhitePaper-StillAllonOneServer-PerforceatScale.pdf
======
fwouts
Google no longer uses Perforce.

[https://cacm.acm.org/magazines/2016/7/204032-why-google-
stor...](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-
billions-of-lines-of-code-in-a-single-repository/fulltext)

~~~
tgtweak
This is correct, but perforce got them to the level they could create their
own tooling around git to make it work.

~~~
acqq
Git? I thought Google uses a custom system?

~~~
BuschnicK
We do. It's called Piper: [https://cacm.acm.org/magazines/2016/7/204032-why-
google-stor...](https://cacm.acm.org/magazines/2016/7/204032-why-google-
stores-billions-of-lines-of-code-in-a-single-repository/fulltext)

------
robaato
FWIW, the metadata file locking was improved with lockless reads as of the
2013.3 release, which made a huge difference to ease of scalability.

Various customers with repos in the PB range these days (metadata TB).

Disclaimer: current Perforce employee

~~~
pvg
_Disclaimer: current Perforce employee_

That's a claimer, rather than a disclaimer!

------
asah
Ha! Remember when source control used locks! Waiting 30-60secs for p4
commands...

"we went from seeing the server blocked routinely for up to ten minutes at a
time in 2005 to gaps of thirty seconds to a minute in 2010..."

~~~
toast0
Now instead, I run git pull; git push in a loop and hope I can get in before a
coworker. Progress?

~~~
williamdclt
Do you really have that many coworkers that people are pushing _every few
seconds on the same branch_?

~~~
toast0
Yes, during the work day, many people would like to commit their changes,
often during the same timeframe. Every step takes a second or two, so there's
plenty of room to get conflicts (I moved closer to the git server, so now I
have an advantage!)

CVS was nice(ish) since changes were independent, any number of people could
check in code to limit of io parallelism. Svn was nice, the server would wait
for a lock and if my changes didn't conflict, they would be applied after the
rest of the pending commits. Git is a PITA, large companies build elaborate
systems to queue commits, but we're not big enough to use that yet.

~~~
fredsted
Does everyone in your company push to master all the time? Or is it different
PRs being merged all the time?

~~~
toast0
Pretty much yes. We like to push to master, and then push to production. Some
teams cherry pick changes to a deployment branch and deploy from there instead
of master.

Edit to add: We may be "doing it wrong", but this is the least effort way to
do centralized development.

~~~
asah
No seriously, consider git branches. It's gotten 100x easier to create,
manage, and merge branch pull requests. Most projects I join these days in
fact "lock" master and you are forced to develop in branches.

