[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recreating of db/revs/XYZ

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Tue, 12 May 2009 02:20:14 -0500

On May 12, 2009, at 01:52, Stawiszynski, Piotr wrote:

> Marcin M. Jessa wrote:
>> Shouldn't it be fairly easy to recreate a text file like that?
>> Valuable
>> data may be lost because of a bagatelle like that...
>> Maybe there is a way to create a "dummy" r420 file and "fool" the
>> system? Or just renumber commits so 421 becomes 420 ?
> Recreate your repo to revision 419, then do a dummy commit (or if
> you can check what was changed in original revision 420 - do
> exactly the same by hand) to raise revision number to 420 and then
> load dump file from revision 421 to the HEAD :)

It will not work. The part you did not quote:

> Marcin wrote:
>> Ryan wrote:
>>> Marcin wrote:
>>>> If not, would it be possible to create a dump of the repository
>>>> from
>>>> rev. number 421 to 509 (my last revision) and to create a new
>>>> repository
>>>> based on that dump?
>>> Not necessarily, since one or more revisions between 421 and 509 may
>>> be based on the missing revision 420. But you can try:
>>> svnadmin dump -r 421:509 /path/to/repos > dumpfile
>> Unfortunately this does not work. I have tried that before:
>> # svnadmin dump -r 421:509 /home/svn/repos/foo_repo > repo_dump
>> svnadmin: Reference to non-existent node '234.2i.r420/189288671' in
>> filesystem '/home/svn/repos/foo_repo/db'

As you see, Marcin was not able to make a complete dumpfile from 421
to HEAD, because at least one of those revisions depends on the
missing revision 420. Revisions are not stored as standalone entities
in the repository. They are stored as deltas against some previous
revision. (The specific number of the depended on revision is
determined by the skip-deltas algorithm [1].)

What you could try is to individually dump each revision from 421
through 509 to a separate dumpfile, like this:

svnadmin dump -r421 /home/svn/repos/foo_repo > 421.dump
svnadmin dump -r422 /home/svn/repos/foo_repo > 422.dump
svnadmin dump -r423 /home/svn/repos/foo_repo > 423.dump

etc. Some of these revisions will not be able to be dumped because of
the dependency on the missing revision 420. But other revisions
should still be intact.

Also create a dumpfile for revisions 0 thru 419:

svnadmin dump -r0:419 /home/svn/repos/foo_repo > 0-419.dump

Once you have a set of files for revisions that you were able to
dump, create a new repository, and load the 0-419 dumpfile into it,
being sure to use the svnadmin load switch --ignore-uuid so that the
new repository has a different UUID than the old one, since its
contents will be different than the old one:

svnadmin create newrepo
svnadmin load --ignore-uuid 0-419.dump < newrepo

Then load in order each of the remaining 421 through 509 revisions
that you were able to dump.

svnadmin load 421.dump < newrepo
svnadmin load 422.dump < newrepo
svnadmin load 423.dump < newrepo

etc. This will result in revisions being renumbered around the ones
that are missing. This may not be what you want, especially if you
have references to revision numbers in your commit messages, or in
comments in your issue tracking system, or elsewhere. If that's the
case, you may want to commit a dummy revision for each missing
revision (for example, for the first missing revision (420) add an
empty dummy file somewhere, and for any additional missing revisions,
add or remove a blank line in that file). In the log message for
those dummy commits you can note that it is a placeholder for a
revision that was lost.

In the end, you may end up losing all changes after revision 420 for
any files affected by revision 420, but other files should be fine.

[1] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-12 09:22:20 CEST

This is an archived mail posted to the Subversion Users mailing list.