Recovering repository with multiple missing rev/ files
Eiren Smith
/eiren
P.S. Other files may also be missing from the revprops/ dir, not just 7437 -- If I'm willing to lose commit messages, can I live without some revprops/ files?
Stefan Sperling
> Dear SVNers,
>
> I'm trying to recover an SVN repository after a hard drive failure.
> From 7,797 revisions, we lost the following seven (7) files from the
> .../repo_dir/db/revs/7/ directory:
>
> 7437 (7-9 Dec 2009) (file also missing from revprops/ dir)
>
> 7461 (16 Dec 2009)
>
> 7519 (8 Jan 2010)
> 7520 (8 Jan 2010)
> 7521 (8 Jan 2010)
>
> 7679 (19 Mar 2010)
>
> 7683 (19 Mar 2010)
>
> This single SVN repository contains many different software
> projects/products. So I would prefer to be able to rebuild my
> repository and only lose the revisions that explicitly depend on
> those seven missing revs/ files, rather than having everything stop
> at rev. 7436. Being able to recover all the way to 7797 might mean
> only five products are affected but all our other products would
> have their history fully restored, which would be excellent.
>
> Is there a way to do this?
Can you still create dumpfiles containing the revisions that
did not get lost? If so, you could stitch together a new repository
and fill in the missing revisions manually (if you still know what
happened in those revisions, or can guess what happened).
See the svnbook section on rewriting history:
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
And see the section called "REVISIONIST HISTORY" of this file:
http://svn.apache.org/repos/asf/subversion/README
> P.S. Other files may also be missing from the revprops/ dir, not
> just 7437 -- If I'm willing to lose commit messages, can I live
> without some revprops/ files?
You should recreate the revprops for all revisions.
Stefan
Eiren Smith
Thank you, Stefan. The second file you mentioned,
http://svn.apache.org/repos/asf/subversion/README
refers to creating "no-op placeholder revision"s. Could someone expand
upon what these are and how to create them?
Thanks,
/eiren
Stefan Sperling
> Sir:
>
> Thanks for your reply. I'll read those references you cited.
>
> >>
> >>P.S. Other files may also be missing from the revprops/ dir, not
> >>just 7437 -- If I'm willing to lose commit messages, can I live
> >>without some revprops/ files?
> >
> >You should recreate the revprops for all revisions.
>
> comments for six of seven of those revisions. If I can rebuild the
> repository with some revprops/ files missing, I can edit the
> comments later. Will this work?
Sure, that will work. You'll need to do a manual commit of the changes
made in lost revisions, and then tweak the revision properties after the
commit is done. See also the 'svnadmin setrevprop' command, which will
help you to set the revision properties (svn:date, svn:author, and svn:log).
Stefan
Eiren Smith
Thank you.
I won't be able to accurately mimic the seven missing changes as most
of them were for binary files (project documentation and some DLLs).
Instead, is there a way to simply say "All future revisions that
depend upon these seven revisions are dead/null" so I can piece the
repo back together with just that minor loss?
Thanks,
/eiren
Brown, Michael
If someone does have the area in question checked out, you'd have a copy of the log in which to use to repair the repository.
Am I off-base?
MB
--
You design it, I'll build it
e-mail: michael...@philips.com
desk: 608-288-6969
cell: 608-206-6843
> -----Original Message-----
> From: Eiren Smith [mailto:eir...@gmail.com]
> Sent: Tuesday, June 15, 2010 11:20 AM
> To: Subversion Users List
> Subject: Re: Recovering repository with multiple missing rev/ files
>
> I won't be able to accurately mimic the seven missing changes as most
> of them were for binary files (project documentation and some DLLs).
> Thanks,
>
> /eiren
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Eiren Smith
> I'm sorta jumping in the middle of this, but doesn't anyone have a
> working copy of the repository checked out, especially the area in
> question? Obviously no one should have the whole trunk checked out,
> as people work with pieces of a repository, specifically a branch,
> for example (like we do).
> If someone does have the area in question checked out, you'd have a
> copy of the log in which to use to repair the repository.
> Am I off-base?
> MB
> --
> You design it, I'll build it
> e-mail: michael...@philips.com
> desk: 608-288-6969
> cell: 608-206-6843
>
>
>> -----Original Message-----
>> From: Eiren Smith [mailto:eir...@gmail.com]
>> Sent: Tuesday, June 15, 2010 11:20 AM
>> To: Subversion Users List
>> Subject: Re: Recovering repository with multiple missing rev/ files
>>
>> I won't be able to accurately mimic the seven missing changes as most
>> of them were for binary files (project documentation and some DLLs).
>> Thanks,
>>
>> /eiren
>
Michael,
Thanks for jumping in.
> If someone does have the area in question checked out, you'd have a
> copy of the log in which to use to repair the repository.
The revisions are not recent. Would the log of someone's working copy
include binary deltas needed to recreate the actual revisions? I doubt
it but it'd be awesome if I were wrong.
/eiren
Ryan Schmidt
> I'm sorta jumping in the middle of this, but doesn't anyone have a working copy of the repository checked out, especially the area in question? Obviously no one should have the whole trunk checked out, as people work with pieces of a repository, specifically a branch, for example (like we do).
> If someone does have the area in question checked out, you'd have a copy of the log in which to use to repair the repository.
> Am I off-base?
Working copies do not contain logs; "svn log" always connects to the repository.
Eiren Smith
Actually, for what it's worth in the current context, SVN has
supported local log cacheing for a while. I don't recall which version
introduced this feature, maybe 1.5 or 1.6.
/eiren
Brown, Michael
>
> Thanks for jumping in.
>
> > If someone does have the area in question checked out, you'd have a
> > copy of the log in which to use to repair the repository.
>
> The revisions are not recent. Would the log of someone's working copy
> include binary deltas needed to recreate the actual revisions? I doubt
> it but it'd be awesome if I were wrong.
>
> /eiren
The log would have a complete history. I do not believe that the working copy has all of the checked in revisions. Being binary, there are no deltas. The complete file have to be checked in (unless something changed recently). I suspect that you are SOL with binary files. With text files you can get the diffs and reconstruct what a file looked like at a particular revision.
All of this leads to another stupid question? Backups?
Backups can be very important. We recently had a person wipe out the whole of our repository structure. It would have been impossible to rebuild the repository with the history (changes). The latest and greatest of each of the branches exists as working copies. In this case, the whole repository was restored from the nightly backups.
MB
--
You design it, I'll build it
e-mail: michael...@philips.com
desk: 608-288-6969
cell: 608-206-6843
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Brown, Michael
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversi...@ryandesign.com]
> Working copies do not contain logs; "svn log" always connects to the
> repository.
Oh well. NEVERMIND
MB
--
You design it, I'll build it
e-mail: michael...@philips.com
desk: 608-288-6969
cell: 608-206-6843
Brown, Michael
> supported local log cacheing for a while. I don't recall which version
> introduced this feature, maybe 1.5 or 1.6.
>
> /eiren
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
Ryan Schmidt
On Jun 15, 2010, at 11:36, Eiren Smith wrote:
>> Working copies do not contain logs; "svn log" always connects to the repository.
>
> Actually, for what it's worth in the current context, SVN has supported local log cacheing for a while. I don't recall which version introduced this feature, maybe 1.5 or 1.6.
This was new to me. I found a reference to such a feature being added to TortoiseSVN in version 1.5:
http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html#log-cache
But I can't find any mention of this existing in Subversion proper. Do you have other information?
Are your users using TortoiseSVN?
Even if they are, my understanding of this feature is that it caches the properties of each revision (like log message, author, date & time). Not sure if it caches the list of files affected by each revision too. But it certainly won't cache the actual changes made to the files in those revisions; the only file contents you have available is the version currently in each working copy.
Eiren Smith
Ryan,
Yes, my users are using TortoiseSVN. I thought it was an SVN feature
(or SVN lib feature) that TortoiseSVN was simply making use of. But I
could be wrong.
Your understanding of how it works is the same as mine. Unfortunately.
/eiren
Eiren Smith
> ...
> Can you still create dumpfiles containing the revisions that
> did not get lost? If so, you could stitch together a new repository
> and fill in the missing revisions manually (if you still know what
> happened in those revisions, or can guess what happened).
>
> See the svnbook section on rewriting history:
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
>
> ...
> Stefan
I don't know how to get past the first revision file that's missing.
When I do an svnadmin dump from the files, it stops at the first
missing revision file and won't go further.
Does anyone know how to get some SVN tool to ignore or handle those
missing revs/ files so I can perform some repo surgery and get it
working despite the seven missing revs files?
Thanks,
/eiren
Stefan Sperling
> On Jun 15, 2010, at 11:31 AM, Stefan Sperling wrote:
>
> >...
> >Can you still create dumpfiles containing the revisions that
> >did not get lost? If so, you could stitch together a new repository
> >and fill in the missing revisions manually (if you still know what
> >happened in those revisions, or can guess what happened).
> >
> >See the svnbook section on rewriting history:
> >http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
> >
> >...
> >Stefan
>
> I don't know how to get past the first revision file that's missing.
> When I do an svnadmin dump from the files, it stops at the first
> missing revision file and won't go further.
You cannot dump the broken revisions.
Let me try to better explain what I meant by providing a small example:
Say only revision 10 was broken.
You'd first create a dump with revisions 1 to 9:
svnadmin dump -r1:9 repos > dump1
Then load that part into a new repository:
svnadmin create newrepos
svnadmin load newrepos < dump1
Then get a working copy from that repository, re-create any changes
made in r10, and commit.
Then you can go on with r11 and following:
svnadmin dump --incremental -r11 repos > dump2
svnadmin load newrepos < dump2
In this example only one revision was broken and skipped during dump.
You may have to do this multiple times since you lost more than one
revision.
> Does anyone know how to get some SVN tool to ignore or handle those
> missing revs/ files so I can perform some repo surgery and get it
> working despite the seven missing revs files?
The commit you make to create r10 will create revision properties, but
their values won't match what you originally had before losing your disk.
However, you can easily change the values by using the svadmin setrevprop
command. There is no need to tweak any files in the repository filesystem
directly.
Hope this helps,
Stefan
Eiren Smith
Stefan,
Thank you very much for your clarification and your help so far.
I considered doing it the way you described. Unfortunately, most of
the seven (7) missing revisions are for binary files (DLLs and DOCs)
and so I can't reproduce their variations by hand. And since SVN is
storing binary deltas, not entire files, for each commit, I believe I
would have to reproduce them perfectly to get this particular solution
to work.
Any ideas how to get around this or where to go from here?
Thanks,
/eiren
Ryan Schmidt
> I considered doing it the way you described. Unfortunately, most of the seven (7) missing revisions are for binary files (DLLs and DOCs) and so I can't reproduce their variations by hand. And since SVN is storing binary deltas, not entire files, for each commit, I believe I would have to reproduce them perfectly to get this particular solution to work.
>
> Any ideas how to get around this or where to go from here?
Perhaps you can do all the "svnadmin dump" steps. Then use svndumptool to filter the problematic files out of all the dumps after which a revision of their history was lost. Then you can load these dumps in order into a new repository.
Eiren Smith
Ryan,
Perhaps. Unfortunately, for just one of the seven missing revisions
(rev. 7519), I don't have a record of what files were changed. I think
that will block me unless I can find a tool that will build a
dependency tree/map for me from that revision through to the HEAD.
Any ideas?
/eiren
Eiren Smith
Anyone:
Any ideas about how to handle this since I can't mimic the changes to
the binary files modified in the missing revs?
Sorry if nudging this is bad form for this list.
/eiren
Daniel Shahaf
Patch svnadmin to skip those particular files (hard-code them) when
parsing a dumpfile?
Daniel Shahaf
Eiren Smith wrote on Fri, 18 Jun 2010 at 10:01 -0400:
> Sorry, I don't understand. Could you expand on that?
>
IIRC, you were suggested to dump the repository (in parts) in order to
recover it. Normally, if you just load these dumpfiles, it will error
at some point due to the missing revisions (which weren't dumped). So
I suggested to recompile svnadmin with a one-off patch that changes the
'svnadmin load' logic to ignore anything in the dumpfiles that touches
one of the files touched in those seven revisions.
Essentially, look up what paths were touched in those seven revisions,
and then patch load.c so that, when it parses from the dumpfile an entry
concerning one of those files, the entry gets ignored (dropped on the
floor) and will not be forwarded to the FS layer as normal (with the aim
of making a commit to the repository-being-loaded-into).
Clearer?
> /eiren
Eiren Smith
Clear. Thanks, Daniel.
If I wind up going that route, I'll do also check revision numbers so
I only start ignoring those files at the point where I'm missing
revision files that include modifications to them, leaving previous
revision history for them intact.
I might also do some fake revisions (to some unrelated dummy files, I
suppose) to keep my revision numbers from shifting.
/eiren
Daniel Shahaf
> On Jun 18, 2010, at 2:53 PM, Daniel Shahaf wrote:
> > Eiren Smith wrote on Fri, 18 Jun 2010 at 10:01 -0400:
> > > On Jun 18, 2010, at 3:07 AM, Daniel Shahaf wrote:
> > > > Eiren Smith wrote on Thu, 17 Jun 2010 at 23:24 -0000:
> > > > > Any ideas about how to handle this since I can't mimic the changes to
> > > > > the
> > > > > binary files modified in the missing revs?
> > > > >
> > > >
> > > > Patch svnadmin to skip those particular files (hard-code them) when
> > > > parsing a dumpfile?
> > > >
> > >
> > > Sorry, I don't understand. Could you expand on that?
> > >
> >
> > IIRC, you were suggested to dump the repository (in parts) in order to
> > recover it. Normally, if you just load these dumpfiles, it will error
> > at some point due to the missing revisions (which weren't dumped). So
> > I suggested to recompile svnadmin with a one-off patch that changes the
> > 'svnadmin load' logic to ignore anything in the dumpfiles that touches
> > one of the files touched in those seven revisions.
> >
> > Essentially, look up what paths were touched in those seven revisions,
> > and then patch load.c so that, when it parses from the dumpfile an entry
> > concerning one of those files, the entry gets ignored (dropped on the
> > floor) and will not be forwarded to the FS layer as normal (with the aim
> > of making a commit to the repository-being-loaded-into).
> >
> > Clearer?
>
>
> If I wind up going that route, I'll do also check revision numbers so I only
> start ignoring those files at the point where I'm missing revision files that
> include modifications to them, leaving previous revision history for them
> intact.
>
> I might also do some fake revisions (to some unrelated dummy files, I suppose)
> to keep my revision numbers from shifting.
>
I'd just do a propset on those same files...
Daniel
(btw, if you need help getting that patch done, feel free to ask)
> /eiren
Eiren Smith
How would setting properties help preserve version numbering?
> Daniel
> (btw, if you need help getting that patch done, feel free to ask)
Thank you very much for your offer, Daniel! I've still got one shot at
recovering some or all of my seven missing revs/ files from that
troubled drive and I'm working on it. If my recovery fails, I'll
likely take you up on your offer.
>> /eiren
Daniel Shahaf
> On Jun 19, 2010, at 2:27 AM, Daniel Shahaf wrote:
> > Eiren Smith wrote on Fri, 18 Jun 2010 at 23:50 -0000:
> > > I might also do some fake revisions (to some unrelated dummy
> > > files, I suppose) to keep my revision numbers from shifting.
> > >
> >
> > I'd just do a propset on those same files...
>
> How would setting properties help preserve version numbering?
>
Setting versioned properties creates a new revision. (And if by chance
you have a revision that touches one of the sevenrevisions' files and
some other files, it keeps the 'log -v' output identical.)
> > Daniel
> > (btw, if you need help getting that patch done, feel free to ask)
>
> Thank you very much for your offer, Daniel! I've still got one shot at
> recovering some or all of my seven missing revs/ files from that troubled
> drive and I'm working on it. If my recovery fails, I'll likely take you up on
> your offer.
>
Good Luck!
> > > /eiren
Daniel
(taking a quick high-level glance at subversion/libsvn_repos/load.c)
Daniel Shahaf
>
> On Jun 15, 2010, at 5:02 PM, Ryan Schmidt wrote:
>
> > On Jun 15, 2010, at 15:37, Eiren Smith wrote:
> >
> > > I considered doing it the way you described. Unfortunately, most of the
> > > seven (7) missing revisions are for binary files (DLLs and DOCs) and so
> > > I can't reproduce their variations by hand. And since SVN is storing
> > > binary deltas, not entire files, for each commit, I believe I would have
> > > to reproduce them perfectly to get this particular solution to work.
> > >
> > > Any ideas how to get around this or where to go from here?
> >
> > Perhaps you can do all the "svnadmin dump" steps. Then use svndumptool to
svndumpfilter or svndumptool, either way it's better than patching (as
I suggested) :-)
(more below)
> > filter the problematic files out of all the dumps after which a revision
> > of their history was lost. Then you can load these dumps in order into a
> > new repository.
> >
>
> Ryan,
>
> Perhaps. Unfortunately, for just one of the seven missing revisions (rev.
> 7519), I don't have a record of what files were changed. I think that will
> block me unless I can find a tool that will build a dependency tree/map for
> me from that revision through to the HEAD.
>
> Any ideas?
>
1. Proceed without this information --- you'll get it from svnadmin's
errors during the load :-)
2. Considering the format of rev files, it might not be that hard to look
in the remaining rev files for where they depend upon the missing ones.
I'm not sure if there is a tool for that, though.
> /eiren
>
Eiren Smith
> On Tue, Jun 15, 2010 at 11:09:39AM -0400, Eiren Smith wrote:
>> Dear SVNers,
>>
>> I'm trying to recover an SVN repository after a hard drive failure.
>> From 7,797 revisions, we lost the following seven (7) files from the
>> .../repo_dir/db/revs/7/ directory:
>>
>> 7437 (7-9 Dec 2009) (file also missing from revprops/ dir)
>>
>> 7461 (16 Dec 2009)
>>
>> 7519 (8 Jan 2010)
>> 7520 (8 Jan 2010)
>> 7521 (8 Jan 2010)
>>
>> 7679 (19 Mar 2010)
>>
>> 7683 (19 Mar 2010)
>>
>> This single SVN repository contains many different software
>> projects/products. So I would prefer to be able to rebuild my
>> repository and only lose the revisions that explicitly depend on
>> those seven missing revs/ files, rather than having everything stop
>> at rev. 7436. Being able to recover all the way to 7797 might mean
>> only five products are affected but all our other products would
>> have their history fully restored, which would be excellent.
>>
>> Is there a way to do this?
>
> Can you still create dumpfiles containing the revisions that
> did not get lost? If so, you could stitch together a new repository
> and fill in the missing revisions manually (if you still know what
> happened in those revisions, or can guess what happened).
>
> See the svnbook section on rewriting history:
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
>
> And see the section called "REVISIONIST HISTORY" of this file:
> http://svn.apache.org/repos/asf/subversion/README
>
>> P.S. Other files may also be missing from the revprops/ dir, not
>> just 7437 -- If I'm willing to lose commit messages, can I live
>> without some revprops/ files?
>
> You should recreate the revprops for all revisions.
>
> Stefan
Dear Stefan,
I'm picking up this oldish topic, which I'm back to after a month of distractions.
> Can you still create dumpfiles containing the revisions that
> did not get lost? If so, you could stitch together a new repository
> and fill in the missing revisions manually (if you still know what
> happened in those revisions, or can guess what happened).
Unfortunately, it appears I cannot create dump files from revisions after a missing revs/ file gap. All the dumpfiles I created which began with a revision past a point of continuity were unusable. They collapsed upon re-import (svnadmin load …) into a single revision instead of hundreds of revisions.
Any idea why that might be or how I might get around it?
Thanks for your continued help,
/eiren
Stefan Sperling
> Unfortunately, it appears I cannot create dump files from revisions
> after a missing revs/ file gap. All the dumpfiles I created which
> began with a revision past a point of continuity were unusable. They
> collapsed upon re-import (svnadmin load …) into a single revision
> instead of hundreds of revisions.
>
> Any idea why that might be or how I might get around it?
Hard to tell from your description, it's a bit vague.
Can you show us exactly what commands you typed while attempting to fix
the problem? And any error message in the output? The more, the better.
Extra noise does not hurt. Feel free to anonymize usernames, path names etc.
Stefan
Daniel Shahaf
> On Fri, Jul 30, 2010 at 01:57:12PM -0400, Eiren Smith wrote:
> > Unfortunately, it appears I cannot create dump files from revisions
> > after a missing revs/ file gap. All the dumpfiles I created which
> > began with a revision past a point of continuity were unusable.
Did you pass --incremental and/or --deltas flags to 'svnadmin dump'?
Eiren Smith
Thanks for your instantaneous response.
When I encountered this dumpfile problem a month ago, I realize now, I was under the (very likely incorrect) impresion that I might be able to do a dump of revs from the middle of the repo before restoring (even with a dummy revision) the missing revisions before the range I was trying to dump. Not sure what I thought it'd do about those gaps, but I hoped it'd find a way to ignore them for the most part. And e.g. "svnadmin dump repo_dir -r100:200 > dumpfile" didn't produce errors, but when I tried to load that dumpfile into a new repo (just to test it), it produced one revision. No errors, just one big revision. I don't know exactly why that was but my working theory is that it was because of the missing revs/ files before those revisions (lower rev numbers than the range being dumped).
Today I see that this "flat" dumpfile problem could perhaps be remedied by creating dummy revisions for any revisions before the revision range I want to dump. Worth a try.
So I tried that, sort of. To do this, I'd need to restore some revisions from my dumpfile backup (the one that's very old) as I can't manually make dummy revisions for those because I don't have modified file lists for those particular missing-from-repo-but-present-in-my-backup-dumpfile revisions. Plus, if I can replace them with real revision files instead of making dummy revisions/commits, awesome, right? Well, I got an error when I tried this. Here's what I did:
1. Loaded my dumpfile backup (the only one I have, the one which is far too old) into an empty repo.
2. Copied revision revs/7/7263 file from that dumpfile-backup-based repo into my production repo (the one missing some revs/ files -- I'll call it my corrupt repo).
3. Tried to dump that corrupt repo to ensure that my transplanted 7263 file was well received. Result:
...
* Dumped revision 7262.
svnadmin: Corrupt node-revision '0-5919.0.r7252/272624'
svnadmin: Missing id field in node-rev
So that's my current barrier. It might seem at this point that I should just dump from 1:7262 and then load that into a new repo because then 7263 will probably drop nicely on top of that without the error above. But if I did that and it worked, I'd get through a few more revisions until I came to the point where my backup dumpfile leaves off (rev 7307 is the last rev in my backup dumpfile) and I'd have to suture my corrupt repo onto that. I must suspect I'd run into the same problem "merging" this dumpfile-based repo with the later revisions from my corrupt repo as I countered after (3) above, which would leave me at an impasse.
Any ideas?
Thanks for your help.
/eiren
Eiren Smith
Not in the case I described in my earlier post. But I did experiment with --incremental and the result there was a tiny little dumpfile, which perhaps just had one revision in it.
I didn't try --deltas. The page
http://svnbook.red-bean.com/en/1.2/svn.ref.svnadmin.c.dump.html
says, "... deltified dumpfiles are more CPU intensive to create ..." which makes me think the deltas get recalculated by --deltas, not just grabbed from the revs/ files directly. So it might not help, huh?
/eiren
Stefan Sperling
> 2. Copied revision revs/7/7263 file from that dumpfile-backup-based repo into my production repo (the one missing some revs/ files -- I'll call it my corrupt repo).
Copying rev files like this most likely won't work.
> 3. Tried to dump that corrupt repo to ensure that my transplanted 7263 file was well received. Result:
>
> ...
> * Dumped revision 7262.
> svnadmin: Corrupt node-revision '0-5919.0.r7252/272624'
> svnadmin: Missing id field in node-rev
To replay changes you've lost, you need to pretend to be a developer
making the changes again.
You need to use svn checkout to get a working copy, make the changes
which happened (and have been lost) in that working copy, and use
svn commit to commit the changes, thereby re-creating the missing
revision. Then load additional revisions on top using svnadmin load.
If you don't know exactly what changes were made in the lost revisions,
maybe you can interpolate the changes by looking at past and
future revisions around the time of the missing changes?
You were talking about changes made to binary files in
http://svn.haxx.se/users/archive-2010-06/0218.shtml so it can be
quite hard to recreate the changes.
Maybe you can get away with just omitting the missing revisions
entirely? Dump all revisions you are able to dump. For the first dump,
use svnadmin dump -r0:X (where X is the last good revision before the
first one that got broken by the disk failure). For any dump
of later revision use svnadmind dump -rA:B with the --incremental option
of svnadmin dump. Then try to load all the dumps in succession.
I'm not sure what you mean when you describe that loading a dump
file into a repository causes a single large revision to be created.
That doesn't make any sense to me. I've never seen this happen.
When this happens, what's the output of the svnadmin load command,
and what's the output of the svn log command? Maybe I'm misunderstanding
what you are trying to say? Please show the exact command you are using
for loading. In fact, it would really help if you could simply post a
transcript of all the commands you have tried running so far, and their
output, without explaining your interpretation of things. This should
help avoid misunderstandings. Based on such a transcript, we could ask
further questions and provide hints, and hopefully help you fix the problem.
Stefan
Daniel Shahaf
> On Jul 30, 2010, at 3:41 PM, Daniel Shahaf wrote:
>
> > Stefan Sperling wrote on Fri, Jul 30, 2010 at 20:05:16 +0200:
> >> On Fri, Jul 30, 2010 at 01:57:12PM -0400, Eiren Smith wrote:
> >>> Unfortunately, it appears I cannot create dump files from revisions
> >>> after a missing revs/ file gap. All the dumpfiles I created which
> >>> began with a revision past a point of continuity were unusable.
> >
> > Did you pass --incremental and/or --deltas flags to 'svnadmin dump'?
>
>
> Not in the case I described in my earlier post. But I did experiment with
> --incremental and the result there was a tiny little dumpfile, which perhaps
> just had one revision in it.
>
cat $dumpfile | grep '^'Revision-number:
> I didn't try --deltas. The page
>
> http://svnbook.red-bean.com/en/1.2/svn.ref.svnadmin.c.dump.html
>
This page is a couple of years old, please try the 1.5 or 1.6 book.
> says, "... deltified dumpfiles are more CPU intensive to create ..." which
> makes me think the deltas get recalculated by --deltas, not just grabbed from
> the revs/ files directly. So it might not help, huh?
>
You can sit here and speculate whether or not it would work, or you can try the
command for yourself and see for yourself whether it works.
> /eiren
Daniel
(echo "Try it and see" >> ~/docs/quotes-I-want-on-T-shirts.txt)
Eiren Smith
Thank you very much for all your help, Stefan. My window of time in which to restore this repository has passed now. So I'm going to restore my old backup and just lose the revisions between then and now. I don't expect to lose any final file versions, so the version history should be the only casualty.
/eiren