> > really run very often, there is good chance that someone
> > calling it will find cached reply just sent to someone else,
> > ready to use as no commit occured after it. Second, if there
> > is cached result of svn blame blahblah.cxx at revision
> > 17784, next svn blame blahblah.cxx comes and repo is at
> > revision 17787, we have to analyze only diffs between 17784
> > and 17787 and apply them to the cached data.
>
> This would work best if we calculated blame server side, which
> we don't, currently.
Obviously. I can not imagine considerable optimalizations of
blame without introduction of the server side support. Although,
maybe some kind of proxy can work (blame server placed behind
clients and the actual subversion server, reused by the clients
but treated as the client by the repository)
> If we were to do so, it might make sense
> to lazily and incrementally compute the blame information,
> as you suggest, or (more simply) to simply always compute
> it at commit time (as others have suggested).
There are three advantages which lazy method has over the commit
time computation:
a) When you build on demand, there is nothing particularly wrong
if you just loose cached data - they will be rebuilt when
needed. So you need not to backup them, you can use algorithms
which lazily store data to disk keeping them in memory for some
time etc. Using cache-on-commit you need to take care for the
cache, provide repair tools etc.
b) Lazy caching can be applied to anything client requests. In
particular, if we have repo at revision 19888 but people start
calling svn blame regarding state at revision 17234, you can
cache it too. It is usually just not an option when one uses
pre-computing algorithm.
c) Lazy caching does not require people to pay for features they
do not use - in particular it does not slow down the commit and
does not occupy system resources if the team has no habit of
frequent blame use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 14:36:12 2004