On Mon, Jan 27, 2014 at 10:25 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> Hi Stefan,
>
>
> On 27 January 2014 11:21, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > On Thu, Jan 23, 2014 at 11:00 AM, Evgeny Kotkov
> > <evgeny.kotkov_at_visualsvn.com> wrote:
> >>
> >> (wants to update the db/current file, but doesn't know the next
> ids)
> >>
> >> svn_fs_fs__find_max_ids()
> >> svn_fs_fs__rev_get_root()
> >> svn_fs_fs__ensure_revision_exists()
> >> ...
> >> (reads the most recent db/current file in order to check the
> >> presence
> >> of this revision. it is reported missing, because we're right
> >> in the
> >> middle of updating the db/current file and cannot do that
> yet,
> >> because we still do not know the next ids)
> >>
> >> So, basically, we're calling a routine that assumes the db/current
> file
> >> is
> >> up-to-date in order to get the information on how to update the
> >> outdated
> >> db/current file. This ends with an "E160006: No such revision 1"
> >> error.
> >
> >
> > Fixed in /trunk and proposed for 1.8.x. The problem was that
> > you had to bump the youngest rev before you could access
> > the latest rev in the destination repo.
> >
> Are you sure about this fix? Bumping youngest rev after copy every
> revision will slow down 'svnadmin hotcopy' significantly. Did we bump
> youngest rev in 1.7.x?
>
This only affects non-sharded repositories with rev-local IDs,
i.e. those in SVN 1.4 format. For those, it is writing 3 files
instead of 2 per rev now.
The question is why people would not upgrade (shard) those
repositories while they are still in use (thus, the need for hotcopy).
The only use-case I can think of is a repo with a moderate number
of revs but those revs being quite large. In that case, updating
one more file per rev shouldn't be significant.
On trunk, we get an extra benefit for that use-case: we can
interrupt the hotcopy at any time and continue with --incremental.
Do you think it is worth adding another patch to 1.8.x that skips
the revnum bump for 1.4 repos?
-- Stefan^2.
Received on 2014-01-29 02:55:56 CET