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

[PATCH] Fix recover/hotcopy erroring out for old FSFS repositories

From: Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
Date: Thu, 6 Feb 2014 06:06:46 +0400


Here is the fixup for the problem I was talking about in
http://svn.haxx.se/dev/archive-2014-01/0160.shtml and partially in

Log message:
Fix a regression in the way recover and hotcopy behave for old FSFS format 1/2
repositories described in http://svn.haxx.se/dev/archive-2014-01/0089.shtml and

In brief, the problem lies in the way the node ids recovery code makes
assumptions about the current state of the db/current file. Namely, the
svn_fs_fs__find_max_ids() wrapper introduced in r1503742 behaves this way:

        (checks the presence of the revision by reading
         the most recent db/current file)

This last assumption renders the recovery procedure useless for old
repositories. The core of the recovery lies in the ability to recreate the
db/current file (which can be missing, out-of-date or even broken) from the
latest revision in the repository. Thus, requiring the db/current contents to
be valid and up-to-date in order to be able to run the recovery does not really
make sense. Moreover, it messes up the hotcopy process, which uses the same
recovery code when updating db/current. In order to update the db/current, we
need to know the node ids. In order to get these node ids, we run the recovery,
which assumes that the db/current file is up-to-date (thus creating a cyclic

This changeset fixes the root cause of the problem by restoring the 1.8.x way
of bootstrapping the node ids recovery. We need to know the root offset in the
revision file, so this can be achieved by parsing the revision file trailer
without assuming (and even knowing) something about db/current. Since r1560643,
we have two regression tests ensuring that recover and hotcopy work for old
repositories. However, this changeset fixes another use case (recovery with
missing or invalid db/current) and it would be nice to have a test checking it.
I splitted the existing recover_fsfs() test into two parts (for the new and the
--compatible-version=1.3 repositories) with the second part actually being the
new regression test.

Finally, with the root cause fixed, we can now drop the first hunk of r1561427,
which is a hotcopy-wide workaround for the erroneous ensure_revision_exists()
assumption. It works by prestamping the db/current with a valid revnum and fake
node ids (0) in order to be able to execute the "real" node ids recovery. This
is no longer required. See http://svn.haxx.se/dev/archive-2014-01/0160.shtml

* subversion/libsvn_fs_fs/recovery.c
  (recover_get_root_offset): New helper function. This one works similiar to
    get_root_changes_offset() in subversion/libsvn_fs_fs/cached_data.c, but
    is much simpler, because it only has to support non-packed revision files.
  (svn_fs_fs__find_max_ids): Use recover_get_root_offset() to get the root
    offset for the node ids recovery.

* subversion/libsvn_fs_fs/hotcopy.c
  (hotcopy_update_current): Do not touch the db/current file before calling

* subversion/tests/cmdline/svnadmin_tests.py
  (recover_fsfs): Move the core of this test into...
  (corrupt_and_recover_db_current): ...this new helper receiving the minor
    version of the server being tested.
    New test. Calls corrupt_and_recover_db_current() with the default server
    minor version. This is effectively the same test as recover_fsfs() was.
    New test. Calls corrupt_and_recover_db_current() with the server minor
    version set to 3.
  (test_list): Add references to new tests in place of the old one.

Patch by: Evgeny Kotkov <evgeny.kotkov{_AT_}visualsvn.com>

Thanks and regards,
Evgeny Kotkov

Received on 2014-02-06 03:07:38 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.