Hello folks. I'm not currently a subscriber, and therefore would appreciate cc's. I will of course respond back to the list.
Here is the gist of my situation. I have a relatively small repo, a little over 1000 commits, 6G total or so (fair amount of binary data), very few users (3). When having a 4th person do a checkout recently, the process (via tortoisesvn) bombed out with a path to a revs file (db/revs/0/586 or something) and input/output error. It became evident very quickly that this was a result of bad sectors, and maybe 6 total files were corrupt. I had backups for all but 1 of them (r772). It later became evident that even my backup for one of them (r390) was corrupt. Copied everything to a new drive, and attempted to start putting everything back together. The normal process for trying to salvage these situations is to dump skipping over the bad revisions such as: svnadmin dump /svn -r 1:389 > dump_0001_0389 svnadmin dump /svn -r 391:771 --incremental > dump_0391_0771 svnadmin dump /svn -r 773:head --incremental > dump_0773_head The problem is that the 2nd command fails because 390 is fubar. (The gist is that I think 390 got truncated somehow because common error messages are thing like "lacks trailing newline" or "node id missing" - forgive me I'm not directly at the computer at the moment.) In all my searching and reading the past few days, I've never really encountered anyone complaining that this process wouldn't work, I guess that's why I'm getting pretty confounded. As further weirdness, if I leave out the --incremental flag, the dump will actually work (and produce a 64G or so file), and complain about r390 at the very end. The problem as you might expect with this is that svnadmin load won't be able to load it because it wants to create everything again the first time it encounters it, and obviously that's useless (bombs out immediately that some item already exists). The original server in question was on ubuntu 12.04 which was running 1.6.17(? definitely some version of 1.6). New disk I made was with 14.04 which runs 1.8 something. The problems seem to happen with both versions of svnadmin. Also, please spare me the backup lecture; believe me, I know. I'm just a programmer trying to clean it up now. If anyone has seen anything like this before or has any suggestions for getting around any of this, that would be great. I would love to be at the point where I could just get some valid dumps and then do what I can to recreate the missing revs, but I can't even get past the dump stage which is exceedingly frustrating. keith
