Some version of #2 might actually not be a horrible idea; companies seem fairly adept at losing old source code, and physical archives run by competent librarians are a little bit more durable and organized. Reminds me of a recent story from engineering (http://wrttn.in/04af1a), but there are plenty in tech as well, where e.g. someone resorts to emailing a former contractor asking if they have a copy of the source code they wrote on their contract job three years ago, because the company has somehow lost it.
I can relate to your link, since I now have a number of hard-drives with a ton of stuff on them that has been copied back and forth and mixed up so many times I am not quite sure what is what and which directories are complete (I have a small suspicion that none of them are). I can't imagine how a large company can possibly figure this out.
But your solution isn't going to help much. In twenty years, do we even have a computer that is capable of reading the old floppy disks? Most computers these days don't come with a floppy drive and the new mac mini doesn't even have a CD drive. Sure USB may be around, but twenty years ago you would have said the same thing about the 3.5inch floppy.
Really if you want to store source code like that, you would have to print it physical paper and store it in a massive archive. And how would you handle changes?
Do you want to print everything each time you do a svn commit? Or just the diff (yeah, that is going to be fun to type in)?
A central server, properly organized and upgraded would properly be the best, but even so it is never going to be very good. In a world were the price of data is very close to nothing, good metadata seems increasingly expensive.
If you have a dedicated archive with dedicated librarians managing it, they can be in charge of migrating the archived data forward whenever a particular storage technology threatens to become obsolete.
