Re: fsfs-improvements branch complete

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_error_t *
+svn_fs_dir_optimal_order(apr_array_header_t **ordered_p,
+ 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
do?

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data