On Wed, Sep 19, 2007 at 02:18:40PM +0100, Malcolm Rowe wrote:
> > A completely separate idea is to work on caching revision files on
> > local disk (so the full text version doesn't have to be regenerated
> > repeatedly).
>
> +1. A server-side rep cache sounds like an excellent idea.
Oh, something that makes any kind of caching hard to do in FSFS is that
the following should work (or, rather, we haven't said it shouldn't, and
haven't prohibited it in any meaningful way):
$ svnserve -d -r .
$ svnadmin create repo
$ svnadmin load repo < dumpfile
Option 1:
$ svn co svn://localhost/repo wc
$ touch wc/foo; svn add wc/foo; svn ci wc -m "log message"; rm -rf wc
# now undo that commit:
$ rm -rf repo; svnadmin create repo; svnadmin load repo < dumpfile
# (how can svnserve [or any process] know to invalidate the cache?]
Option 2:
$ svnadmin hotcopy repo repocopy
$ svn co svn://localhost/repo wc
$ touch wc/foo; svn add wc/foo; svn ci wc -m "log message"; rm -rf wc
$ svn ls svn://localhost/repocopy
# oops! Two filesystems open with the same UUID. Hope we're not just
# using UUID/path/rev as the cache key.
I've been wondering whether to check for 'same UUID, different
filesystem' at open time and disallow it (since we already have data
structures that are keyed off the UUID). I'm concerned that that might
cause more problems that it solves (like: I wouldn't be suprised if it
breaks our test suite).
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Fri Sep 21 17:45:01 2007