Re: Blame caching (was Re: Case study: Mono switches to Subversion)

My $0.02:

Couldn't you just cache and update (as needed) the last blame results
in the WC, i.e. add a "blame-base" subdirectory in the .svn directory
which stores the last results of "svn blame" along with the then-current
revision.

Future runs of "svn blame" could check if the last results are still
valid, and optionally do a "smart" update of the locally cached file
as needed.

You'd still have an initial "svn blame" time that is 10x that of
"cvs annotate", but future runs would be accelerated.

If the blame cache update is only done when "svn blame" is run, then
the WC code probably doesn't need to change (i.e. will it care about
another subdir?), and then you can focus on optimizing the update of
the blame results on the client end.

A happy side-effect of this type of caching would be to allow for
off-line blame use so long as the last blame revision is the same
as the current WC. That could be automated with a script that does:

     svn up; svn blame >/dev/null

before you go off-line...

[FWIW, the cache file need only store the user and line range info,
not the full text]

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org