> So it keeps your .git fairly light weight (... compared to ...) Team Foundation
And you can tell from how the product is being used. Where I work, we use TFS and you literally need to have committee meetings before a new branch is made.
You need to agree on long term strategies, you need to agree on branch hierarchy (because TFS cannot merge without one), you need to replicate all-the-things(tm) for your new branch, you need to adjust your versioning-strategy for this branch, and possibly future branches which may come and may not ever collide with this one, because TFS branches are massive and carved in stone. They are forever. Etc etc.
You never branch more than once a year. In the world of TFS, doing such would be madness, haphazard. Or at least you would need a full team doing nothing but branching and merging and integration. And good luck trying to find qualified people willing to have that as their day-job.
With git you branch every single time it makes sense, usually several times a day. And your life is nicer because of it.
It's funny how such technical decisions results in such huge and enormous visible changes to how a product is being used.
Somewhere deep in Microsoft there are probably one or more engineers crying right now seeing the effects of their (back then) seemingly innocent decision, as they themselves are forced to deal with TFS in their daily work and they see how nice the gitters have it.
Internally Microsoft largely uses a fork of Perforce called SourceDepot. Branching in P4 is about as easy and lightweight as any centralized version control system has ever managed, though still quite a bit heavier than git obviously.
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.
And you can tell from how the product is being used. Where I work, we use TFS and you literally need to have committee meetings before a new branch is made.
You need to agree on long term strategies, you need to agree on branch hierarchy (because TFS cannot merge without one), you need to replicate all-the-things(tm) for your new branch, you need to adjust your versioning-strategy for this branch, and possibly future branches which may come and may not ever collide with this one, because TFS branches are massive and carved in stone. They are forever. Etc etc.
You never branch more than once a year. In the world of TFS, doing such would be madness, haphazard. Or at least you would need a full team doing nothing but branching and merging and integration. And good luck trying to find qualified people willing to have that as their day-job.
With git you branch every single time it makes sense, usually several times a day. And your life is nicer because of it.
It's funny how such technical decisions results in such huge and enormous visible changes to how a product is being used.
Somewhere deep in Microsoft there are probably one or more engineers crying right now seeing the effects of their (back then) seemingly innocent decision, as they themselves are forced to deal with TFS in their daily work and they see how nice the gitters have it.