Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <b...@reser.org> wrote:
>
> > On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> > <philip.mar...@wandisco.com> wrote:
> > > Looking at the repository path ('CONVERSION' and 'test') and the fact
> > > that the error vanished when httpd was restarted is it possible this
> > > involved a temporary repository being replaced by another repository at
> > > the same path with the same UUID. If that happens I think apache may
> > > have been using the in-memory cache associated with the old repository
> > > when accessing the new repository.
> >
> > Realistically the UUID really shouldn't be used by caching to decide
> > if it's looking at the same repo. Since it's exposed to clients users
> > doing dump/load cycles are going to modify repos and end up with the
> > same UUID. I'd suggest that we add another UUID that isn't exposed to
> > the client and that svnadmin can't modify with load. The cache system
> > should use this UUID for cache purposes.
> >
>
> +1. Let's call that UUID "instance ID".
How about the inode number of the db/ directory?
The issue of "instance UUID" already came up in the context of svnsync
write-through proxy mirrors, to distinguish the slave from the master.
