Keith Johnson wrote on Wed, Feb 25, 2015 at 13:14:56 -0600: > On Wed, Feb 25, 2015 at 12:33 PM, Andreas Stieger <andreas.stie...@gmx.de> > wrote: > > > Hi, > > > > Am 25. Februar 2015 18:48:37 MEZ, schrieb Keith Johnson <k33...@gmail.com > > >: > > > > >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. > > > > Make a backup of all existing working copies including the pristine > > content cache under ".svn". > > > > When I last recovered a zeroed out block for someone I recreated the > > broken revison N by committing an indentical change into a repository with > > 1..N-1 loaded, with content from working copies and partial backups. The > > remaining incremental dumps then applied cleanly. The fixed rev file could > > be dropped back into the production area as it was. > > > > Hi Andreas, thanks for the response. > > The revision in question is over a year old, so I'm not sure I can put it > back exactly as it was (guess all I can do is try my best). I assume > there's no way to actually get historical data from pristine - that's just > a cache of current documents, correct?
In theory, yes. In practice, the cache may contain everything since the last time you ran 'svn cleanup'. See: http://subversion.apache.org/docs/release-notes/1.7#wc-pristines
