Thanks Ryan..
You are correct that the svnadmin dump command is failing for the
entire repository. Here's the error message that the ISP provided to
me:
# svnadmin dump repo | bzip2 > repo.dump
* Dumped revision 0.
<snip revision 1 through 161>
* Dumped revision 162.
svnadmin: Decompression of svndiff data failed
Now, I don't even know positively that this is a BDB database b/c I
can't get my hands on it (yet). Working on that. I believe the ISP has
tried a recovery using "svnadmin recover" but I'm not sure why it
didn't work. It's possible they are stored in FSFS format and they
haven't communicated that clearly to me..
Here's my follow up question. Let's take the following example:
Revision 1-44: intact
Revision 44-82: corrupt (can't be dumped)
Revision 83-200: intact
Will "svnadmin dump [path] -r NX:NY" allow me to dump Revisions 1-44
and Revisions 83-200 and then "svnadmin load" these two files
sequentially?
I'm concerned that the second file (rev 83-200) will fail when I try to
load it. The doc's are not clear about this (as best as I could tell).
Of course, as soon as I get a copy of my binary repository I can try it
myself, but I'm trying to educate myself as much as possible now, and I
appreciate the advice as to the best path out of this mess.
Thank you again,
Steve
At 12:12 PM 4/18/2007, Ryan Schmidt wrote:
>On Apr 18, 2007, at 11:55, Steve Midgley wrote:
>
>>I seem to have a corrupted SVN database (BDB) and my ISP can't
>>figure out how to recover it. (It's possible it's recoverable but
>>neither they nor I am sure how to do it). I believe the ISP even
>>posted to this list about the issue.
>>
>>The repository is not totally corrupt, as I can still check in and
>>out files from various portions of the repository - only one area
>>of the repo appears broken, and no files can be accessed from
>>there. Fortunately, this area is trivial/unimportant, so all my
>>critical files are accessible (for now!).
>>
>>What I'd like to do is export all my files/revisions from the
>>critical areas and re-import them into a new repository. (Unless
>>someone has a lower risk / easier idea).
>>
>>I've already written and run a script which exports each revision I
>>care about into a separate local folder, along with a file that
>>contains the "commit message" for that revision. I've now run this
>>script against all the repository folders/revisions which I care to
>>preserve. No errors!
>>
>>So now I have a (fairly massive) set of folders and revision
>>message files stored locally. This is a good backup in all events
>>and allowed me to sleep well last night. :)
>>
>>My question is this: I'd like to "import" these folders
>>sequentially into a new repository. But this doesn't seem to gibe
>>with how Subversion operates (it wants a checked out version to
>>operate against a repository). I can't just run "import" over and
>>over since the files will already exist in the repository after the
>>first import run..
>>
>>My current idea is a little kludgy which is why I'm writing for
>>advice. Here's some pseudo-code of my idea:
>>
>>0) (Create new repository)
>>1) Import first revision into repository
>>2) Loop through remaining revisions
>>2.a) Check out current "head" revision to a working folder
>>2.b) File copy ("cp") .svn folders from this head revision to the
>>next revision I want to import
>>2.c) "Commit" this next revision folder to SVN
>>2.d) [Loop ends]
>>
>>I'm a little concerned as to whether this will even work. There's a
>>lot about the .svn folders that I don't understand. For example,
>>will this correctly handle deleted files or folders? Will it catch
>>added files/folders? It seems like it will work for modifications
>>just fine at least?
>
>It sounds like you are making this *extremely* complicated. It
>should
>be fairly simple. Just use "svnadmin dump" on the ranges of
>revisions
>that you want to preserve (assuming that "svnadmin dump"ing the
>entire repository does not work for some reason -- and if that's the
>case, you should post the error message here). Then you can load
>those dumpfiles into a new repository and be on your way. I
>personally would recommend not using BDB this time and going for an
>FSFS-based repository. Also make sure your ISP has the latest
>Subversion, currently 1.4.3, so as to avoid any bugs which may have
>been present in earlier versions which may have contributed to your
>current situation.
>
>
>--
>
>To reply to the mailing list, please use your mailer's Reply To All
>function
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 18 21:47:11 2007