News for hackers. Stuff that matters.
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by fwouts on Thursday July 26, 2018 @03:04AM (#17615584)
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by tgtweak on Thursday July 26, 2018 @03:13AM (#17615638)
This is correct, but perforce got them to the level they could create their own tooling around git to make it work.
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by jounker on Thursday July 26, 2018 @03:45AM (#17615777)
Google replaced perforce with Piper, a perforce compatible system written in-house. This system was not based on git.

There were systems that allowed you to mirror portions of piper into local git repo, giving you a git-like experience on top of piper, but the underlaying system was piper and not git. (At this point my knowledge is 4 years out of date.)

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by acqq on Thursday July 26, 2018 @03:17AM (#17615656)
Git? I thought Google uses a custom system?
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by BuschnicK on Thursday July 26, 2018 @04:58AM (#17616051)
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by robaato on Thursday July 26, 2018 @06:41AM (#17616401)
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

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by pvg on Thursday July 26, 2018 @11:37AM (#17618288)
Disclaimer: current Perforce employee

That's a claimer, rather than a disclaimer!

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by asah on Thursday July 26, 2018 @08:00AM (#17616743)
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..."

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by toast0 on Thursday July 26, 2018 @11:18AM (#17618122)
Now instead, I run git pull; git push in a loop and hope I can get in before a coworker. Progress?
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by williamdclt on Thursday July 26, 2018 @11:38AM (#17618298)
Do you really have that many coworkers that people are pushing every few seconds on the same branch?
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by toast0 on Thursday July 26, 2018 @11:59AM (#17618469)
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.

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by fredsted on Thursday July 26, 2018 @12:45PM (#17618827)
Does everyone in your company push to master all the time? Or is it different PRs being merged all the time?
Re:Still All on One Server: Perforce at Scale (2011) [pdf] by toast0 on Thursday July 26, 2018 @02:34PM (#17619736)
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.

Re:Still All on One Server: Perforce at Scale (2011) [pdf] by asah on Saturday July 28, 2018 @01:06PM (#17633962)
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.