On 9/21/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> 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?]
It doesn't have to. The files are still valid at certain revisions.
There is already a layer that knows whether that file "exists" at the
requested revision.
>
> 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.
UUID stands for Universally Unique Identifier. You've failed as soon
as you have two different filesystems with the same UUID.
Yes, the svn test suite does this, and tests fail when caching is enabled.
I have an updated version of DannyB's memcached caching patch. I had
to add a hook to the test suite to restart memcached after every
repository creation step. This enables the test suite to pass with
caching enabled.
> 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).
This seems like the right thing to do. I don't know if there would be
special cases where you would have to skip the check.
> I'm concerned that that might
> cause more problems that it solves (like: I wouldn't be suprised if it
> breaks our test suite).
The test suite would need to be modified to generate properly unique
UUIDs. The current behavior is broken (IMHO).
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 21 21:17:59 2007