5 ms·

> To do that, you'd really need the entire 2.11BSD distribution in source control. So the real problem would be that you'd need to start with...patch...level..

> To do that, you'd really need the entire 2.11BSD distribution in source control. So the real problem would be that you'd need to start with...patch...level...zero. :whoa: I might be misunderstanding, but I don't think this is true. As long as there's a complete snapshot to start from anywhere in the revision history, it's possible to apply each patch in reverse (as far back as possible), even if it doesn't get all the way to patch level 0. Then later, if earlier patches are found, these can be applied in reverse and the branch rebased.

jacoblambda 6y ago
You can do this but rebasing plays havoc on a lot of git integrations. Every time you insert a commit into an earlier spot, it changes the hash of every commit after it which has the potential to cause all kinds of problems for systems assuming git hashes are permanent.
- progman32 6y ago
  For sure, this is very bad practice when using git for forward development. When working in reverse, a lot of things go out the window :) The way I see it, git's main role here would simply be a way to standardize patch format, not its usual role as a distributed software development aid.
  - bsdimp 6y ago
    Git's role would be to record the system incrementally as each patch is applied. I've already worked all the way back to the unpatched system. I assume that if I got it right, then I'll be able to rebuild. I've mostly been able to, and I'm investigating the mostly. Plus, I'm making sure that it's 100% reproducible so anybody can down the TUHS artifacts, run my scripts and have release 0 tapes, and a git repo of all the changes. And historians will be able to see what's definitely original, and my reconstructions of missing changes to programs. Those we'll never know to a higher degree of 'consistent with everything else'
breput 6y ago
The confusion might be around the term "patch". These can be sometimes be simple diff patches. Or they can be multi-step processes, including reboots, all wrapped up into a single "patch". For example: https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/467 https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch... I recently updated from patch level 462 to 469 (the most recently patch available) and even with excellent documentation, it was an involved process. If you look all the way back to the first set of patches (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/001-009.tar.bz2 https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...) there isn't even documentation for the most part. Some diffs, some random tar files, and some "Remove everything above the #! /bin/sh line." patches.
- progman32 6y ago
  Ah. I understand the difficulty now, thanks. Some patches might not even apply in reverse!
  - bsdimp 6y ago
    It's hard to reverse apply 'rm /usr/src/bin/ld.c' in the instructions to patch 160, for example. You have to reconstruct ld.c from 2.10.1BSD, and then add missing changes to get it to work...
    - qubex 6y ago
      Exactly: deletions is what came to my mind instantly and if you hadn’t raised the issue then I would have.

jacoblambda 6y ago

You can do this but rebasing plays havoc on a lot of git integrations. Every time you insert a commit into an earlier spot, it changes the hash of every commit after it which has the potential to cause all kinds of problems for systems assuming git hashes are permanent.

progman32 6y ago
For sure, this is very bad practice when using git for forward development. When working in reverse, a lot of things go out the window :) The way I see it, git's main role here would simply be a way to standardize patch format, not its usual role as a distributed software development aid.
- bsdimp 6y ago
  Git's role would be to record the system incrementally as each patch is applied. I've already worked all the way back to the unpatched system. I assume that if I got it right, then I'll be able to rebuild. I've mostly been able to, and I'm investigating the mostly. Plus, I'm making sure that it's 100% reproducible so anybody can down the TUHS artifacts, run my scripts and have release 0 tapes, and a git repo of all the changes. And historians will be able to see what's definitely original, and my reconstructions of missing changes to programs. Those we'll never know to a higher degree of 'consistent with everything else'

breput 6y ago

The confusion might be around the term "patch". These can be sometimes be simple diff patches. Or they can be multi-step processes, including reboots, all wrapped up into a single "patch". For example: https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/467 https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch... I recently updated from patch level 462 to 469 (the most recently patch available) and even with excellent documentation, it was an involved process. If you look all the way back to the first set of patches (https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patches/001-009.tar.bz2 https://www.tuhs.org/Archive/Distributions/UCB/2.11BSD/Patch...) there isn't even documentation for the most part. Some diffs, some random tar files, and some "Remove everything above the #! /bin/sh line." patches.

progman32 6y ago
Ah. I understand the difficulty now, thanks. Some patches might not even apply in reverse!
- bsdimp 6y ago
  It's hard to reverse apply 'rm /usr/src/bin/ld.c' in the instructions to patch 160, for example. You have to reconstruct ld.c from 2.10.1BSD, and then add missing changes to get it to work...
  - qubex 6y ago
    Exactly: deletions is what came to my mind instantly and if you hadn’t raised the issue then I would have.