David Glasser wrote:
> Braindump re: implementing svn_ra_replay_range for ra_svn:
>
> We can get a similar speedup with ra_svn. There are two ways to do it:
That would be cool!
>
> * Explicit server support.
>
> Either add a new replay-range command or an optional second revision
> argument to replay. In either case we would fall back to a bunch of
> replay commands for servers that don't support it; we could use a
> capability to detect it or just note that (for a new command) the
> command wasn't implemented. Upside: guaranteed to work. Downside: no
> performance gain possible against 1.4.x servers.
I think this matters less for ra_svn than ra_dav. Svnserve setups are
typically (not always) inside the LAN or at least under central control
and as such easier to upgrade.
> * Rely on details of current implementation.
>
> In practice, you really can just write a bunch of replay commands to
> the server and then process all the responses. However, technically
> the server may issue an auth request before handling each command;
> this is currently hardcoded to be a trivial auth request which
> requires no response. For reasons related to Issue #2712, we might
> actually want to sometimes put in a real auth request. (If anonymous
> users can read the repo, and you try to replay a revision where some
> of the paths are not readable by anonymous users, then replay will
> leave those paths out, even if the client could have given a username
> that can read it if the server had asked for it.) So this would
> prevent us from fully fixing Issue #2712.
>
> I would lean towards adding a new command. If people agree I'm happy
> to do the coding.
I'm not an ra_svn expert, but I'm +1 on adding a new command based on
your reasoning.
> I'll point out that since the fallback here is just equivalent to "run
> svn_ra_replay" a bunch of times, and that's what ra_local and ra_neon
> need to do also, it might be a good idea to stick a project-private
> function in the ra-loader which simulates svn_ra_replay_range in terms
> of svn_ra_replay.
I've implemented a client-side fallback in r27584, -5. While this
implementation works, it's not ideal. Other clients directly using the
ra api's will have to implement a similar wrapper or not use
replay_range. The alternative is to do this in the ra layer, but that
would require a place to share ra code (libsvn_ra_util?), which I didn't
want to add right now.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 4 22:29:06 2007