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
> cf.
> 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?
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1010619
Received on 2009-01-08 00:04:32 CET