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/undernea

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.