Ramkumar Ramachandra wrote on Fri, Jul 23, 2010 at 23:41:21 +0530:
> Hi Stefan,
>
> Stefan Sperling writes:
> > Can you explain what you mean by "resume support"?
> > svnadmin dump has no such feature AFAIK.
>
> I like to think of svnrdump as a combination of `svnsync` and
> `svnadmin dump`. To illustrate resume support, consider the following
> scenario: Suppose a server administrator wants to backup a remote
> repository (with a large number of revisions) over a slow unreliable
> connection:
>
> Here's the current way of doing it (using `svnsync`): run `svnsync
> init` first, and then `svnsync sync`. When the connection breaks,
> re-run `svnsync sync` and it'll just resume dumping.
>
> Here's my proposed new way of doing it (using `svnrdump`): run
> `svnrdump` with a revision argument and redirect the output to a
> dumpfile. When the connection breaks, run `svnrdump resume` with the
> dumpfile as the argument. To implement resume support, we have to
> actually read the dumpfile ofcourse.
>
Or, you could have svnrdump report the highest revision it dumped, and the
admin can remember that and invoke svnrdump -r N+1:HEAD next time. (Much
cheaper than parsing the entire dumpfile --- which you would have to do in
order to figure how many revisions it contains.)
(One can parse that already out of the "* Dumped revision %ld" notifications;
if this use case is important, we may want to have a switch to suppress all but
the last notification...)
Received on 2010-07-23 20:22:00 CEST