If the original develoeprs had used Git, they'd be mostly fast-forward merges. Those are the default merge operation in Git, and they don't appear as merge commits in a repo.
However, there commits start 33 years before Git was created. Merge commits were not even a concept back than.
Correct. I had used both at work up until around 2005. The idiot large companies I worked at did not believe in Source Code Control. That is the one thing I liked about RCS/SCCS, once I checked out an item, no one could check in their changes unless they contacted me. Forcing a coordinated manual merge between us.
I tried to get our org on to something for a while, but got massive push back until 5 or 6 years ago when they setup corporate wide paid githup repo.
Before that, I found a small group of developers around 2005 that used CVS and they allowed me to leverage that for my group. But of course I was the only one who used it.
Back then I guess people loved loosing source code, which happened a lot until git.
I convinced a software company to use a version control system (RCS on shared disk) back in 1993. To make it work we had to setup a network — Ethernet over (thin) coaxial cable at the time. This was so new to us that we didn't know we needed to use terminators on the two cable ends.
30 years ago (1995) open source offerings: mostly CVS for large projects and RCS for smaller ones. On the proprietary side, the aged SCCS was available and used, while Perforce and Microsoft Visual Source Safe were being launched.
Don't know about 30 years ago but 25 years ago in a small shop, the code was on a network share, on the production server.
And whenever a code file was locked on the server, the Devs went into the server room (aka the break room with a computer) and rebooted the server. The production server that was used by 30+ employees.
Right: I don't have direct experience, but from what I recall reading it was only over the Subversion era that it really became strikingly abnormal for a professional software team to use no VC software at all. When there was software it could be ... exotic. The FOSS culture's pre-SVN norm of "CVS everywhere" put it notably ahead of others.
IN 1995, I think there were some proprietary offerings, one company in Massachusetts was purchased by IBM back then.
But on the minis (non-DEC) I worked on back then, there was nothing. We kept a specific drive that had source current source, but once in production you just copied the change version to that drive, replacing what was already there. As you can guess, changes disappeared often :) And there was no change history, but we would tag each line changed with our 3 character ID.
I published an updated extension of this post's linked article in Empirical Software Engineering. You can read it without a paywall at https://rdcu.be/b7FzE. You may also be interested to see the actual GitHub repository at https://github.com/dspinellis/unix-history-repo.
670,000 commits. Thats big. But only 2K merges? I assume push straight to master in most cases?
If the original develoeprs had used Git, they'd be mostly fast-forward merges. Those are the default merge operation in Git, and they don't appear as merge commits in a repo.
However, there commits start 33 years before Git was created. Merge commits were not even a concept back than.
I don't think either SCCS or RCS tracked merges, so everything looks like a new revision.
Correct. I had used both at work up until around 2005. The idiot large companies I worked at did not believe in Source Code Control. That is the one thing I liked about RCS/SCCS, once I checked out an item, no one could check in their changes unless they contacted me. Forcing a coordinated manual merge between us.
I tried to get our org on to something for a while, but got massive push back until 5 or 6 years ago when they setup corporate wide paid githup repo.
Before that, I found a small group of developers around 2005 that used CVS and they allowed me to leverage that for my group. But of course I was the only one who used it.
Back then I guess people loved loosing source code, which happened a lot until git.
I convinced a software company to use a version control system (RCS on shared disk) back in 1993. To make it work we had to setup a network — Ethernet over (thin) coaxial cable at the time. This was so new to us that we didn't know we needed to use terminators on the two cable ends.
also rebases instead of merges wouldn't count as merges
I don't think the concept of a rebase existed before Bitbucker and Git.
It wasn't called rebasing, but working on a shared branch and updating that branch while having local changes did the same thing.
What did source control look like 30 years ago? Was merges used a lot? I have only used Subversion and Git.
30 years ago (1995) open source offerings: mostly CVS for large projects and RCS for smaller ones. On the proprietary side, the aged SCCS was available and used, while Perforce and Microsoft Visual Source Safe were being launched.
(Meanwhile, apparently MS itself continued using SLM, the in-house source-control system which had been commercialised as MS Delta, internally until about 2000. https://wiki.c2.com/?MicrosoftDelta https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97... https://ricomariani.medium.com/super-brief-notes-on-early-so... https://news.ycombinator.com/item?id=44255526 )
A stack of labelled backup tapes.
Whereas today, we have a stack of virtual backup tapes plus a DAG on the labels.
(OK, only 30 years ago we were using SCCS or maybe already RCS.)
Don't know about 30 years ago but 25 years ago in a small shop, the code was on a network share, on the production server.
And whenever a code file was locked on the server, the Devs went into the server room (aka the break room with a computer) and rebooted the server. The production server that was used by 30+ employees.
Right: I don't have direct experience, but from what I recall reading it was only over the Subversion era that it really became strikingly abnormal for a professional software team to use no VC software at all. When there was software it could be ... exotic. The FOSS culture's pre-SVN norm of "CVS everywhere" put it notably ahead of others.
IN 1995, I think there were some proprietary offerings, one company in Massachusetts was purchased by IBM back then.
But on the minis (non-DEC) I worked on back then, there was nothing. We kept a specific drive that had source current source, but once in production you just copied the change version to that drive, replacing what was already there. As you can guess, changes disappeared often :) And there was no change history, but we would tag each line changed with our 3 character ID.
I published an updated extension of this post's linked article in Empirical Software Engineering. You can read it without a paywall at https://rdcu.be/b7FzE. You may also be interested to see the actual GitHub repository at https://github.com/dspinellis/unix-history-repo.
Right. The title of this submission should have a "(2015)".
Hopefully UNIX v4 will soon be in there too :)
Indeed! The repo includes some v4 elements: https://github.com/dspinellis/unix-history-repo/tree/Researc...
The provided kernel predates the actual edition by a few months. It is based on https://www.tuhs.org/Archive/Distributions/Research/Dennis_v..., which matches V4 more than V3.
Interesting to see the decisions they took regarding which flavours they chose to include.
[dead]
[dead]