On Tue, Dec 11, 2012 at 9:29 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 12/10/2012 10:53 AM, C. Michael Pilato wrote:
>> 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.
>
> Well, this turns out to be a little more sticky than I'd hoped.
>
> It's easy enough to add a "send_complete_start_revision" flag to
> svn_ra_replay_range() which causes the first transmitted revision to be a
> full dump of the tree as of that revision. But the svn_ra_replay_range()
> API also allows folks to specific whether they want *real* content change
> information, or just placeholder notifications for modified file content and
> node properties. Seems kinda yucky to transmit a full tree snapshot when
> the caller has asked not to get any real content mods; and we don't have a
> readily available way to send a full tree snapshot sans real content.
>
> Those technical challenges aside, I've since started to doubt the wisdom of
> adding special treatment of the starting revision to this API anyway. I'll
> continue pondering other options.
>
What about my earlier suggestion?
"""
On Thu, Dec 6, 2012 at 11:04 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> Is there an easy way to make svnrdump always use "sendall" mode? That
>>> would remove the release blocker we have about this command not
>>> working correctly with Serf and it seems like something we ought to be
>>> able to implement independent of these other questions.
>>>
>>
>> A bit of a hack, but after the config is read from file/registry and
>> before svnrdump creates the ra_session we can set the global or per
>> server-group "bulk-updates" option in memory to true.
>> Is this for dump only?
>
> 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.
"""
It'd still require an ra API change, like
guarantee_depth_first_order(), which ra_serf will use to limit the nr.
of connections to 1, and probably only svnrdump will every use.
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
>
Lieven
Received on 2012-12-12 21:02:53 CET