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

Re: FSFS optimization

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-09-21 17:44:41 CEST

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

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.