When I worked in Google a couple years ago, they were using Perforce and branching was extremely hard (it was P4 with extensive internal tooling around/underneath it, no idea how representative it was of normal P4).

It took me about a year to realize how bad it really is: eventually I found my way to a "how to create a dev branch" document starting with:

    "Last year Dev Wossname wrote a useful mail showing how to create a dev branch and got most of the details right :-)  This howto explains it in more detail and fixes a few points."
    Then followed a quite few pages with a dozen manual actions doing somewhat intimate things to levels of P4 I had not previously heard of...
    Oh, and it created the branch at the *company-wide root level*, e.g. `gmail/` -> `gmail_dev_branch_2012/`.  No pressure !-)

It then took a few more days until the horror of that opening sentence sunk in. Native large-scale branching was so rare that it was almost a lost art!

[There were also several "lightweight" branch-like techniques based on symlink magic, FUSE filesystems and more magic. Those were routinely used for freezing a release build, with option to hot-patch it — but IIRC it was impossible to merge back onto the main tree.]

In practice things weren't that bad because (A) Google got really good flow (especially continuous testing) for everybody working close to HEAD, (B) personal branches were easy and common:

- Fresh checkout directories were cheap [should have been frightfully expensive but clever scripts and a FUSE filesystem fixed that]. - Every CL (commit progressing through code review iterations) was effectively a feature branch. - People who wanted more used a somewhat crazy, but very workable, internal tool mirroring a growable {time,space} subset of P4 into local a git repo and back onto P4.

My P4 is very rusty, but back when I used a vanilla install a branch was basically just a copy operation from one part of the namespace to another, and then setting up your view to point to that new spot (or setting up a separate view for it if you wanted). This was before any integration with git (or, indeed, the existence of git at all), as well.

Subversion mostly copied the way p4 did it, but without the view control stuff (where there's a server-registered and quasi-versioned description of what local file paths map to what server paths) that perforce has/had.

Hmm, that doens't sound bad. I don't remember (nor fully understood) why it was that complicated at google. At a wild guess it's ultimately connected to google's choice to keep all company code in a single humongous repo, which required a lot of later creativity to keep P4 from collapsing under the weight...

I would think that the amount of data wouldn't be the thing that would make p4 fall over (it's pretty decent at that), but the number of users. P4, iirc, stores all client state server side, even to what files you're editing. So if you had to work around anything, it was probably that, and I can definitely see how that would break the ease of the workflow.