3 ms·

670,000 commits. Thats big. But only 2K merges? I assume push straight to master in most cases?

by phplovesong 11mo ago

mprovost 11mo ago
I don't think either SCCS or RCS tracked merges, so everything looks like a new revision.
- lionkor 11mo ago
  also rebases instead of merges wouldn't count as merges
  - DSpinellis 11mo ago
    I don't think the concept of a rebase existed before Bitbucker and Git.
    - ahartmetz 11mo ago
      It wasn't called rebasing, but working on a shared branch and updating that branch while having local changes did the same thing.
- jmclnx 11mo ago
  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.
  - DSpinellis 11mo ago
    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.
keybored 11mo ago
What did source control look like 30 years ago? Was merges used a lot? I have only used Subversion and Git.
- DSpinellis 11mo ago
  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.
  - leoc 11mo ago
    (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://wiki.c2.com/?MicrosoftDelta https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97855 https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97... https://ricomariani.medium.com/super-brief-notes-on-early-source-control-systems-at-microsoft-d8fce7e8db12 https://ricomariani.medium.com/super-brief-notes-on-early-so... https://news.ycombinator.com/item?id=44255526 https://news.ycombinator.com/item?id=44255526 )
- jmclnx 11mo ago
  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.
- kps 11mo ago
  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.)
- whynotmaybe 11mo ago
jlokier 11mo ago
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.

670,000 commits. Thats big. But only 2K merges? I assume push straight to master in most cases?

mprovost 11mo ago

I don't think either SCCS or RCS tracked merges, so everything looks like a new revision.

lionkor 11mo ago
also rebases instead of merges wouldn't count as merges
- DSpinellis 11mo ago
  I don't think the concept of a rebase existed before Bitbucker and Git.
  - ahartmetz 11mo ago
    It wasn't called rebasing, but working on a shared branch and updating that branch while having local changes did the same thing.
jmclnx 11mo ago
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.
- DSpinellis 11mo ago
  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.

keybored 11mo ago

What did source control look like 30 years ago? Was merges used a lot? I have only used Subversion and Git.

DSpinellis 11mo ago
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.
- leoc 11mo ago
  (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://wiki.c2.com/?MicrosoftDelta https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97855 https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97... https://ricomariani.medium.com/super-brief-notes-on-early-source-control-systems-at-microsoft-d8fce7e8db12 https://ricomariani.medium.com/super-brief-notes-on-early-so... https://news.ycombinator.com/item?id=44255526 https://news.ycombinator.com/item?id=44255526 )
jmclnx 11mo ago
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.
kps 11mo ago
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.)
whynotmaybe 11mo ago

jlokier 11mo ago

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.