It is cut and dry. You need to be effective at collaborating with other people. I use git for everything even my own projects. How can you collaborate copying code around effectively?
All git really does is copy code around for you. ;) It’s certainly nice that it keeps track of the code it copies around, but I’m sure you’re aware that before git, Linus and everyone developing Linux collaborating extremely effectively by emailing code patches around.
I don’t know exactly what is cut and dry, but as I age it’s endearing to hear young people having trouble imagining effective collaboration before git. That says something very good about the tools we have now, and I hope they keep improving. But the days before git and even before CVS or email or internet weren’t quite the Stone Age some people imagine, there was plenty of effective collaboration, so maybe you can take that knowledge and do some research to answer your question. Knowing that effective collaboration is possible by copying code around, what then is truly important? We’re collaborating faster and on a larger scale now, it’s getting better, but it was exciting then (possibly more than today) and working well enough to get us to where we are now, right?
Well, version control wasn't always a thing and people got by just the same. So I can see how it could be done but the key is 'effectively' and the ability to quickly review and accord changes to a larger code base as well as to compare versions in a divide-and-conquer manner to see where a particular issue got introduced is priceless. So it would be a bit like trying to drive with the handbrake on, you can do it but it isn't an advantage.
Having Googled it, CVS came out in 1990, and there wer other pre cursor systems. So, pre-widespread internet and collaboration, yes, maybe people had some limited control systems that worked, but I don't think it even comes close.
CVS came out in 1986, and it is built on top of RCS, which dates to 1983.[0]
RCS was an alternative to SCCS, which was written for the IBM System/370 in 1972.[1][2]
All of these are very workable for software development by a co-located group of engineers. They are full-featured, not "limited". CVS is currently used by OpenBSD.[3]
And the car was invented in the early late 1800's and yet there are people who use bicycles.
The date when something is invented or comes into common usage does not automatically imply that everybody should use them. Though in the case of version control there are no good reasons not to use it that I'm aware of, even so, some people don't seem to require it to be able to be both productive and qualitatively at a very high level.
everyone has a copy. you email patches to someone whose job it is to review them and maintain the release version. they publish that to everyone else who uses it to replace their local version. repeat.
So they DO have source control. It's just 100% manual instead of (partially) automated.
I wonder what happens when the "source master" receives everybody's tarballs at the end of the work week? Manually inspect them all and manually merge the source files? Or, pick one at random and tell the engineers to merge on their own next week?
