On 11/9/05, Philip Martin <philip@codematters.co.uk> wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
> > What I came up with was the idea of exposing the svn_repos_replay API
> > (which is what svn_repos_dump uses under the hood), so you can
> > actually drive an editor through the correct sequence of commands
>
> I think that bypasses the auth stuff, doesn't it?
Yeah, that's the other thing I still need to implement. Knew I forgot
to mention something ;-)
> > /**
> > + * Replay the changes from @a revision through @a editor and @a edit_baton.
> > + *
> > + * If @a send_deltas is @c TRUE, the actual text and property changes in
> > + * the revision will be sent, otherwise dummy text deltas and null property
> > + * changes will be sent instead.
> > + *
> > + * @a pool is used for all allocation.
> > + *
> > + * @since New in 1.4.
> > + */
> > +svn_error_t *svn_ra_replay (svn_ra_session_t *session,
> > + svn_revnum_t revision,
> > + svn_boolean_t send_deltas,
> > + const svn_delta_editor_t *editor,
> > + void *edit_baton,
> > + apr_pool_t *pool);
> > +
>
> That's at least one round trip per revision isn't it, is that going to
> be a problem when people want to replay large numbers of revision?
Yeah, it's one round trip per revision, but for non-trivial commits
you're spending a fair amount of time getting the actual content, so
I'm not really sure how much the round trips hurt.
> I suppose allowing a single request to replay a large number of
> revisions might be a bit of a denial-of-service problem. Perhaps we
> would need a replay hook to control it?
That occurred to me, but honestly, this is actually less data being
transferred than you'd end up with from doing diff and update, so I'm
not sure it's that big a deal. You can likely cause more of a load
problem via the existing APIs than you can with this one.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 10 04:12:18 2005