Ask HN: Do you ever truly use your revision history?

Your first example hits the nail on its head. I use code history all the time to understand the context in which a bug or weird looking piece of code was introduced. If the developer who wrote it isn't around anymore, or can't remember the details, then this information is really crucial to gain confidence that changing or removing the code won't just introduce another obscure bug because you didn't understand the reasoning behind it.

It's crazy how in agreement we are that keeping our records is important for legal defense, debugging, auditing, finding out how things came to be etc

Then for our users it's like you can have one name and one name only if you change it, it's going to be that name forever in the past too

Tables should have revisioning on as a default

That's indeed useful, some IDEs/editors are able to show the commit message just above the line of code you're looking at, providing a lot of useful context when troubleshooting. Of course it does require discipline on our part, as it can fall over when a dev has been through hours of messages like "trying something..."

Not frequently, as some other commenters have claimed to do. But when I do, it's invaluable.

I build custom automation equipment, which involves individual 100-400 hour projects. They're developed in a continuous scratch-to-complete flurry, with a few days of revision after customer review and installation, a year's warranty that typically involves 1-5 on-site days, and an annual "we never read the manual please remind us how to calibrate it again" for the next decade. Very little maintenance coding, lots of fresh feature development.

I disagree that there's diminishing value to older commits. You're more likely to forget what you did the farther back you go!

I'd estimate that I use revision history maybe 0-2 times in a typical project. But that's an easy way to recover a couple days of work that would otherwise need to be rewritten from memory, or worse, reengineered from scratch! You can write a lot of commit messages in 16 hours, so one incident where you can recover two days of work makes two months of using version control without ever referencing the history worth it. Plus, it's a nice security blanket for me, I don't worry about commenting around old code or making changes to a reference implementation I'm modifying because I know it will be in version control.

I do think it's exceedingly unlikely that you'll suddenly decide to revert to the state of your codebase from 20 years ago. If you transitioned to Git and kept the SVN repository around for the rare occasion when you need to reference it, at least in my projects, you'd be able to do so without much trouble.

Hell yes, I use it daily. I'm in AAA gamedev and the codebase I deal with goes back 20+ years. The last 10 years are readily accessible in Perforce and the rest can be found in another version control system. I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se. With thousands of engineers that have come and gone, this is incredibly useful information in addition to the code itself.

IMHO revision history is just as valuable to a company as the code itself.