Did you ever have the misfortune of having to use Microsoft Sourcesafe?
Yes. It was perfect. This was in the mid or late 90s. Our group was about 5 to 20 people. Sourcesafe ran on our manager's desktop machine. He left it on when he went home, so everyone in the group would be able to use the SCM. Our development process was completely linear (no branches, no tags, no merging), and files were committed one at a time. It was flawless, and super easy to use. But that was in a world where requirements were much simpler.
Our development model was one of long-lived development branches that were merged back to trunk shortly before they were deployed. This meant that the development branches had trunk merged to them several times during their lifetimes. ...
I was in a similar situation in the early 2000s. Our project was to integrate multiple components that came from different research / development groups: A cluster file system, an object store layer, a cluster management system (config, hardware control, scheduler), and the code for actual OSDs (yes, we had object disks, that was considered hip and cool at the time). That meant our "coding" work consisted mostly of merging separate streams of changes that came from different directions, and different SCMs of their own. After considerable research, we picked Perforce, since it had (a) the best merge support in the industry, and (b) a reputation for superb customer service and hand holding. This is in the spite of the fact that our company (IBM) had a half dozen SCMs they sold (including Rational ClearCase). Perforce worked beautifully, very little hassle, when things didn't work I just called their 800 number and got help. The cost of a few thousand $ per developer was a great investment.
We moved to Git and all those problems went away. It was almost magical.
I had the opposite experience with git, about 10 years late, in the mid 2010s. Here we had a large project (probably millions of lines of source), and one guy by himself working offline over two years to make a major modification to it. Because that modification was very risky, it could not be done on the main trunk, and had to remain on a branch. The problem was that at the same time as the one person working full-time on his branch, a group of a few dozen people were modifying the trunk continuously. For a while, the one branch developer was willing to do a weekly merge of trunk changes back into his branch. Git did horribly badly, and most merging had to be done by hand. After about 3 months, he gave up. Unfortunately, I was dumb enough to volunteer to help him, and manage just the weekly merging. The first week took me several days to catch up. After that, for a few months it was a few hours per week. Then it went to several days per week. For about one month, I worked full-time simply merging code all day long (to support one developer, but one super hard working one), fighting git every step of the way. To use your language: this task killed the merge monkey.
We decided to give up, and our colleague did all his development on an obsolete branch, knowing that the code would have to be thrown away. After about two years of working on the project, we literally threw all the code away, looked at the diffs, and in the span of a few weeks retyped it from scratch into a short-lived branch.
That horrible experience is why I hate git. And I have developed a strong allergy to branching. It can be made to work, if the semantic distance between trunk and branch stays reasonably small, and if you are using a REALLY good tool (the only one I know firsthand is Perforce).
If you look back at the best book about software engineering (The Mythical Man Month), it clearly explains that every software development group (of ~10 people) needs to include one librarian. In the 60s, when the book was written, the job of the librarian was filing new code (on punched cards) into the drawers of code (steep cabinets with lots of punched cards). Today the librarian is the person who operates the SCM for the developers, and becomes an expert on merging, branching, and cherry picking. Having that task distributed to all software engineers is insane, as it is a different skillset. A normal company wouldn't ask the software engineers to cook lunch in the kitchen either.
gameoftrees.org
