4 ms·

Fun story indeed! I worked in the Cocoa group when we migrated from cvs to git. But it wasn't exactly cvs, it was ocvs, which was an ancient forked version of

Fun story indeed! I worked in the Cocoa group when we migrated from cvs to git. But it wasn't exactly cvs, it was ocvs, which was an ancient forked version of cvs that handled certain directories (nibs) as tar files. There was no direct importer from cvs to git, so we had to go through Subversion as an intermediate. This was Cocoa so its history was very long, but the earliest history turned out to be mangled, so some poor fellow was tasked with learning how to repair CVS history, only so it could be migrated to git. Once we got to git our lives were so much better. I'm glad we skipped svn. ocvs man page for any masochists reading this: https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-5.1/cvs_wrapped/man/ocvs.1.auto.html https://opensource.apple.com/source/cvs_wrapped/cvs_wrapped-...

mrpippy 4y ago
Did that cvs history date back to NeXT? Or was there some initial Rhapsody import?
justinator 4y ago
I'm curious why it wouldn't make sense to just think, "Before THIS DATE we just don't care about history anymore". I look at my main project and I'm fairly happy to forget about 90% of the branches I have hanging around and half the lifetime of coding it, and it's just 100k LOC. (except I haven't. Why haven't I?)
- saagarjha 4y ago
  It’s generally useful to have history around when you’re digging through a codebase for bugs or curiosity.
  - justinator 4y ago
    But where do you draw the line when migrating to a superior source control system isn't possible because of your current source control system? If curiosity is what you're wanting to allow, keep the current source control system on ice, and move everything to the superior one at its current state + a few releases back. Save a decade or two. It seems to me a version (sic!) of technical debt otherwise.
    - gsnedders 4y ago
      I think it's especially valuable to try and be complete when doing a migration from a centralised VCS to a decentralised one; once you manage to migrate the repository once, you can then avoid any necessity to maintain servers for it. In extreme, you could just distribute a tarball of the decentralised VCS, hence all you need is the ability to distribute a tarball, which is a lower bar than maintaining servers for it indefinitely.

mrpippy 4y ago

Did that cvs history date back to NeXT? Or was there some initial Rhapsody import?

justinator 4y ago

I'm curious why it wouldn't make sense to just think, "Before THIS DATE we just don't care about history anymore". I look at my main project and I'm fairly happy to forget about 90% of the branches I have hanging around and half the lifetime of coding it, and it's just 100k LOC. (except I haven't. Why haven't I?)

saagarjha 4y ago
It’s generally useful to have history around when you’re digging through a codebase for bugs or curiosity.
- justinator 4y ago
  But where do you draw the line when migrating to a superior source control system isn't possible because of your current source control system? If curiosity is what you're wanting to allow, keep the current source control system on ice, and move everything to the superior one at its current state + a few releases back. Save a decade or two. It seems to me a version (sic!) of technical debt otherwise.
  - gsnedders 4y ago
    I think it's especially valuable to try and be complete when doing a migration from a centralised VCS to a decentralised one; once you manage to migrate the repository once, you can then avoid any necessity to maintain servers for it. In extreme, you could just distribute a tarball of the decentralised VCS, hence all you need is the ability to distribute a tarball, which is a lower bar than maintaining servers for it indefinitely.