subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <jcor...@gmail.com>
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
Date Wed, 13 Feb 2013 23:49:37 GMT
On Thu, Feb 14, 2013 at 12:11 AM,  <rhuijben@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@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

Mime
View raw message