[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-11-18 17:00:22 CET

On Thu, Nov 18, 2004 at 02:35:46PM +0100, Marcin Kasperski wrote:
> 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.

These are good arguments. On the con side:

a.) The actual effort involved in a lazy calculation may be
significantly higher (since the fulltexts would need to be
reconstructed, again).

b.) The cache itself would need some amount of concurrency
control if it were read/write; no locking would be necessary
in the read-only case.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 16:59:03 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.