On Wed, Jan 7, 2009 at 2:03 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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. =)
>
> 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
> multiple -r's.
The reason I'm a bit hesitant about that is that at the
svn__cl_log()-level it's ambiguous to differentiate between:
% svn log -r<X>:<X-1> -r<X-1>:<X> -cX -c-X
These, of course, get expanded inside main.c to (start/end pairs):
X/X-1, X-1/X, X/X-1, X-1/X
Previously, we'd interpret -cX or -c-X as only wanting the log for X
and not X-1 - the used_change_arg only indicates that it was used
anywhere and doesn't specify *which* revision in the range it applies
to. With that expansion, you can't tell what the user really wants if
there's a mix.
Does that explain the situation a bit better?
>> - 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().
That's the cop-out, but, yah, we could do that instead of revving the
RA APIs. Anyone feel strongly here? -- justin
Received on 2009-01-07 23:17:04 CET