Global svn_client_update4 (apr_array_header_t **result_revs, const apr_array_header_t *paths, const svn_opt_revision_t *revision, svn_depth_t depth, svn_boolean_t depth_is_sticky, svn_boolean_t ignore_externals, svn_boolean_t allow_unver_obstructions, svn_boolean_t adds_as_modification, svn_boolean_t make_parents, svn_client_ctx_t *ctx, apr_pool_t *pool)

Multiple Targets

Up for debate: an update on multiple targets is not atomic. Right now, svn_client_update only takes one path. What's debatable is whether this should ever change. On the one hand, it's kind of losing to have the client application loop over targets and call svn_client_update() on each one; each call to update initializes a whole new repository session (network overhead, etc.) On the other hand, it's a very simple implementation, and allows for the possibility that different targets may come from different repositories.

Global svn_fs_copied_from (svn_revnum_t *rev_p, const char **path_p, svn_fs_root_t *root, const char *path, apr_pool_t *pool)

See how people like this, it can always be hidden behind the curtain if necessary.

Global svn_fs_file_contents (svn_stream_t **contents, svn_fs_root_t *root, const char *path, apr_pool_t *pool)

kff: I am worried about lifetime issues with this pool vs the trail created farther down the call stack. Trace this function to investigate...

Global svn_opt_print_generic_help2 (const char *header, const svn_opt_subcommand_desc2_t *cmd_table, const apr_getopt_option_t *opt_table, const char *footer, apr_pool_t *pool, FILE *stream)

Why is stream a stdio file instead of an svn stream?

Global svn_opt_subcommand_help3 (const char *subcommand, const svn_opt_subcommand_desc2_t *table, const apr_getopt_option_t *options_table, const int *global_options, apr_pool_t *pool)

Why does this only print to stdout, whereas svn_opt_print_generic_help() gives us a choice?

Global svn_wc_conflict_version_t

Consider making some or all of the info mandatory, to reduce complexity.