On 12/07/2012 02:39 AM, Lieven Govaerts wrote:
>> AFAIK, it is only dump where the svnrdump tool fails when using Serf.
>> Because of the Ev1 stuff. Using bulk-updates ought to avoid that
>> issue.
>
> Actually, my proposed hack of forcing ra_serf to use bulk update mode
> is not going to work. If the server has SVNAllowBulkUpdates set to
> Off, bulk update mode isn't available, the server will ignore any
> requests from the client and force skelta mode.
>
> If I remember correctly the issue here was responses arriving out of
> order due to multiple parallel connections. So the fix until svnrdump
> has moved to Ev2 is to stick to one extra connection for all the file
> content requests, so all of those responses arrive in sync.
> Don't know how easy that is to do, I wonder if we have a simple
> mechanism that allows a client to pass ra implementation specific
> options.
IIUC, the problem with svnrdump occurs only for the single revision at the
start of a non-incremental dump. svnrdump runs svn_ra_do_update2() in such
a way as to pretend that it's doing a checkout. After that one revision, it
runs a loop around svn_ra_replay_range().
Perhaps there's an opportunity here to solve two problems at once.
What if we revved the svn_ra_replay_range() API in such a way that it could
now handle this "initial revision" scenario? We might add an 'incremental'
flag that parallels what 'svnadmin dump' and 'svnrdump dump' do. This would
get us to a single RA API used for revision replays (replay_range, instead
of a combination of do_update + replay_range), which simplifies how replays
are done from an API perspective. Of course, under the hood, the RA
implementations of the new replay_range2() would probably just use the same
update mechanics to handle that initial revision when not in incremental
mode, but ra_serf's particular implementation would be free to choose
"send-all" mode in this one scenario to do exactly that.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-12-10 17:40:51 CET