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?
Stefan
Received on 2010-11-30 15:52:58 CET