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.
--ben
---------------------------------------------------------------------
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