When the server needs to transmit the list of changed paths
in a revision, its memory usage is O(#changes), i.e. practically
unbound. The problems are:
* FS and repos API require a full collection of all changes
Most consumers simply scan that data once. So, they can
just as well work on a one change at a time basis as a
* The data types are different, so we end up with two copies.
A revised svn_fs_path_change_t with identical
svn_repo_path_change3_t can fix this. Minor adjustments
to the element data types further improve efficiency.
I've played with a revised version of svn_fs_paths_changed
and svn_repos_get_logs to use callbacks for the individual
path changes. Effectively, the FS layer can now pump the
info through the repos / authz filter into the RA layer.
I'll commit the changes to /trunk over the next couple of weeks,
mostly on weekends. There will be two-way conversion between
old and new APIs to facilitate regression testing. The old API will
get deprecated once all users have migrated.
Received on 2016-01-31 12:03:25 CET