We currently fetch all the revision numbers (inserted in an array in the
wrong order.. which we then reverse) and then start delivering changes.
I would be surprised if the revision/path walk step would make a huge
difference compared to delivering the actual changes (We now always do that
before the first revision, so it is not slower than the current server side
algorithm). But if it is we can optimize it later.
Bert
Sent from Windows Mail
*From:* Johan Corveleyn <jcorvel_at_gmail.com>
*Sent:* February 14, 2013 12:50 AM
*To:* rhuijben_at_apache.org
*CC:* dev_at_subversion.apache.org
*Subject:* Re: svn commit: r1445973 - in /subversion/trunk/subversion:
include/svn_ra.h include/svn_repos.h libsvn_repos/rev_hunt.c
tests/libsvn_repos/repos-test.c
On Thu, Feb 14, 2013 at 12:11 AM, <rhuijben_at_apache.org> wrote:
> Author: rhuijben
> Date: Wed Feb 13 23:11:33 2013
> New Revision: 1445973
>
> URL: http://svn.apache.org/r1445973
> Log:
> Allow svn_ra_get_file_revs2() and svn_repos_get_file_revs2() to report
file
> revisions backwards. This to allow optimizing 'svn blame' in a future
> Subversion release without having to wait for yet another server upgrade
> to support this new feature.
>
> * subversion/include/svn_ra.h
> (svn_ra_get_file_revs2): Update documentation.
>
> * subversion/include/svn_repos.h
> (svn_repos_get_file_revs2): Update documentation.
>
> * subversion/libsvn_repos/rev_hunt.c
> (svn_repos_get_file_revs2): Update comment. Detect reversed arguments,
> which would originally just return an error or no revisions..
> and in that case reverse the revision array before walking it.
Great!
One question though: wouldn't it be (potentially much) faster if the
server would retrieve the revisions from the FS directly in reversed
order, rather than retrieving them in ascending order and reversing
the array?
Right now, for a given PATH_at_REV, I suppose the FS first needs to walk
history backwards to find the first revision, then serve all the
versions from the first to the last (which is then reversed in
svn_repos_get_file_revs2). I guess the FS could just as well start
returning file versions immediately while walking history backwards.
Perhaps all this can be done streamily so the server can start sending
file versions to the client (for diffing), while the FS is still
walking ... ?
Or do you consider that a separate future improvement, which can be
done at any time later?
Another thought (that may already have come up elsewhere in the
context of "reverse blame"): cancellation support all the way,
especially if all this can be done streamily. So the client has the
ability to tell the server that the blame is already fully calculated
based on the youngest 100 revisions, and the server (and FS) needn't
retrieve the older 9900 revisions of the file :-).
--
Johan
Received on 2013-02-14 01:20:45 CET