On Tue, Nov 30, 2010 at 03:52:06PM +0100, Stefan Sperling wrote:
> On Tue, Nov 30, 2010 at 03:40:01PM +0100, Stefan Sperling wrote:
> > We could forbid callbacks from calling any other libsvn_client function,
> > and provide all information they will ever need as arguments. Careful
> > consideration of possible use cases for an API would allow us to do this.
> > E.g. for proplist, it's clear that the callback will want a path and a
> > list of properties. It wouldn't be allowed to retrieve additional information.
> > This approach keeps memory usage during a crawl as low as possible and
> > could get away with a single query per operation.
> > However, this approach might break existing third party code using callbacks
> > which call into libsvn_client. It won't be trivial to support 1.6.x semantics
> > ("you're free to call whatever you want") on top of a 1.7.x API placing
> > restrictions on the callbacks.
> >
> > Another possibility is partitioning the problem by running queries per
> > directory. The walk_children crawler would crawl per directory instead
> > of per path. All queries work in units of directories and no callbacks
> > are invoked while an sqlite transaction is active. Callbacks are free to
> > do whatever they want, but the crawler will need to deal with resulting
> > edge cases such as the current directory disappearing from the DB or
> > from disk (our current node walker seems to account for missing paths
> > only before the first invocation of the callback -- it doesn't reckon
> > with the callback deleting paths or removing relevant data from the DB.)
> > This approach will cause memory usage to be a function of the number
> > of directory entries. It will also be slower than the first approach
> > because one or more queries are issued per directory.
> >
> > Given our backwards-compatibility policy I'd say we'd have to go with
> > the second option. Can anyone think of any other options?
>
> Could we use approach one during libsvn_client<->libsvn_wc interaction
> (e.g. during propset -R) with private APIs, and use approach two for
> client<->libsvn_client interactions (e.g. during proplist -R or status)
> with public APIs?
This thread seems to have idled out.
I intend to take a closer look at this approach unless someone can
provide reasons for why it might be a bad idea.
Stefan
Received on 2010-12-11 14:39:07 CET