Justin Erenkrantz wrote:
> I got frustrated that svn log can't take multiple revisions on the
> command line (which contributes in part to svnmerge.py being
> unbearably slow)...and, well, this patch works for me. =) Against,
> my svn server (located in a far far away nether land *grin*), this
> reduces the time from:
> svn log -rX -rY -rZ
> takes 7.354 seconds
> for i in X Y Z; do svn log -r$i; done
> takes 18.162 seconds
> (The time to do add'l revs with this is essentially O(1)+6secs
> compared to ~6secs per revision previously. Yay.)
> Before I proceed any further with this patch (ie unit test), I'd like
> to get some feedback to make sure I'm on the right path. If anyone
> wants to help out, lemme know. =)
> Outstanding issues/questions:
> - Can we support multiple -c syntax?
> - How can we support limit - as currently implemented, limit is
> handled by the RA layer, so...uh...
> - Moving some of the parameter checks from svn/log-cmd.c into
> svn_client_log5 seems like the right thing to do, but...
> Thanks. -- justin
> (Attached and inline as I have no idea what CN's MX is gonna do.)
> Have 'svn log' take multiple revs options to optimize session usage.
> * subversion/include/svn_client.h
> (svn_client_log5): New log variant that takes a set of ranges.
> (svn_client_log4): Deprecate.
> * subversion/libsvn_client/deprecated.c
> (svn_client_log4): Wrap log5.
> * subversion/libsvn_client/log.c
> (svn_client_log4): Rename to...
> (svn_client_log5): this; take array of revisions and loop logs; moves some
> of the checking that the client did into here; optimize session-opening.
> * subversion/svn/log-cmd.c
> (svn_cl__log): Prevent -c used with multiple revs; use svn_client_log5;
> move manipulation of unspecified ranges into svn_client_log5.
> * subversion/svn/main.c
> (main): Permit log to have multiple revs.
> Index: subversion/include/svn_client.h
> --- subversion/include/svn_client.h (revision 35065)
> +++ subversion/include/svn_client.h (working copy)
> @@ -1953,9 +1954,29 @@ svn_client_status(svn_revnum_t *result_rev,
> * If @a ctx->notify_func2 is non-NULL, then call @a ctx->notify_func2/baton2
> * with a 'skip' signal on any unversioned targets.
> + * @since New in 1.6.
> + */
> +svn_error_t *
> +svn_client_log5(const apr_array_header_t *targets,
> + const svn_opt_revision_t *peg_revision,
> + const apr_array_header_t *revision_ranges,
> + int limit,
> + svn_boolean_t discover_changed_paths,
> + svn_boolean_t strict_node_history,
> + svn_boolean_t include_merged_revisions,
> + const apr_array_header_t *revprops,
> + svn_log_entry_receiver_t receiver,
> + void *receiver_baton,
> + svn_client_ctx_t *ctx,
> + apr_pool_t *pool);
> + * Similar to svn_client_log5(), but takes explicit start and end parameters
> + * instead of an array of revision ranges.
> + *
> + * @deprecated Provided for compatibility with the 1.5 API.
> * @since New in 1.5.
As long as we're rev'ing the API, would it make sense to create an argument
struct, so we don't have to continue rev'ing the API every stinkin' time we add
a new boolean parameter?
Received on 2009-01-08 00:04:32 CET