history-tracing bug in 1.2 client (was Re: svn 1.2.1 client x20 slower than 1.1.x)

OK, this is a genuine bug, thanks for pointing it out again Michael
(and sorry we didn't fix it earlier!) I was able to reproduce the
bug by running the svn 1.2 client in gdb against the openib.org
server and watching what it was doing.

In short:

The svn 1.2 client is requesting *all* logs from the server, before
it ever issues an 'ls' request. And there's no reason for it do be
doing that. That explains the 2 minute delay.

In long:

As I suspected, the 1.2 svn client is doing history-tracing during an
'svn ls', when an svn 1.1 client is not.

Because openib.org is running svn 1.0, the client's attempt to call
svn_ra_get_locations() fails, so it falls back to running
slow_locations(), which ultimately calls svn_ra_get_logs().

In gdb, I can see that slow_locations() is called with arguments of
{start_revnum, end_revnum, peg_revnum} all set to 2829 (which is
HEAD). Yet somehow, at libsvn_client/ra.c:660, we call
svn_ra_get_logs() on a range of "youngest through r1". And the
revision 1 is hard-coded!

So instead of noticing, "hey, all the revisions are identical" and
doing zero history requests, the current logic says to
unconditionally fetch all logs back to r1. I have no idea why this
is. Can somebody else comment?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 10 22:51:31 2005