Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> After two weeks now, I finally completed the fsfs format 6 refactoring
> and improvement work on said branch. Please review. See also
> http://svn.haxx.se/dev/archive-2013-07/0385.shtml for the "split up
> fs_fs.c" part of it.
> If there are no objections, I will merge the code in the week of Aug 26th.
I'm wondering whether this:
+/** Take the #svn_fs_dirent_t structures in @a entries as returned by
+ * #svn_fs_dir_entries for @a root and determine an optimized ordering
+ * in which data access would most likely be efficient. Set @a *ordered_p
+ * to a newly allocated APR array of pointers to these #svn_fs_dirent_t
+ * structures. Allocate the array (but not its contents) in @a pool.
+ * @since New in 1.9.
+ svn_fs_root_t *root,
+ apr_hash_t *entries,
+ apr_pool_t *pool);
should have two pools? I can see that in lots of cases the optimal
ordering is something the backend produces with little effort, that's
the case for the current implementations, and so a scratch pool is not
necessary. Lots of FS functions are single pool because they were
defined before we started using two pools. What should new functions
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
Received on 2013-08-08 12:43:02 CEST