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

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.