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. =)
As you know, I'm +1 on the concept.
> Outstanding issues/questions:
> - Can we support multiple -c syntax?
You should get this for free today by the same code tweak that lets you use
> - How can we support limit - as currently implemented, limit is
> handled by the RA layer, so...uh...
Could you add (inside the svn_client_log() logic) a simple intermediate
log-entry-callback wrapper that decrements a "global" limit and then passes
the return log entry off to the one provided to the svn_client_log() API?
Basically, the code would be counting the number of entries returned, which
would then affect the limit passed to the next iteration of svn_ra_get_log().
> - Moving some of the parameter checks from svn/log-cmd.c into
> svn_client_log5 seems like the right thing to do, but...
No opinion here.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2009-01-07 23:03:44 CET