In the distant past, I used to use CVS for my home projects, before moving to SVN, and latterly to Mercurial (because it seemed that git would never play nice on Windows -- so, not long before Github for Windows came out, then). For various reasons, I thought I'd sweep the cobwebs off one of the old projects that still lived in the CVS repo backup.
I also had a copy of the WinCVS installer from way back when, so I expected just to run it up, check things out and be done.
It turned out that that was when the fun began. I started with looking for a CVS/Mercurial bridge, but they all seemed to be Unix based and included dire warnings about CVSNT being problematic. And it's not as if I really needed the old check-in history. So back to the long-hand way.
WinCVS installed OK, but the CVSNT sub-installer just hung. Try the latest (coming up to its 7th birthday) release. No joy there either, just the same hang. Discover that CVSNT itself is now being charged for -- there surely is indeed one born every minute! Try Tortoise CVS -- which completes its install of the included CVSNT, but (as I find after much googling for the error message
cvs server: Couldn't open default trigger library: No such file or directory
later) has failed to install the default_trigger.dll file.
Start looking for the CVS file format and how it handles binaries, because there are image files in the repo module as well as just code; and discover that it's the same as RCS format.
Inspiration finally dawns. The problems cited by cvs2svn with CVSNT in migrations is CVSNT in its role as a command line client, and not with the repo it talks to! Fire up cygwin and check everything out smoothly, after three hours beating around the bush.
The moral of the story : it's not enough to keep the back-ups -- you have to be able to usefully read them as well! Even if it's just some hobby code, rather than NASA downlink telemetry from the 1960s.