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

Re: Unexplained "Corrupt representation" errors with 1.8.1

From: Daniel Shahaf <danielsh_at_apache.org>
Date: Thu, 1 Aug 2013 03:38:41 +0000

On Thu, Aug 01, 2013 at 05:31:56AM +0200, Branko Čibej wrote:
> On 01.08.2013 04:17, Daniel Shahaf wrote:
> > Stefan Fuhrmann wrote on Wed, Jul 31, 2013 at 19:58:06 +0200:
> >> On Wed, Jul 31, 2013 at 7:48 PM, Ben Reser <ben_at_reser.org> wrote:
> >>
> >>> On Wed, Jul 31, 2013 at 7:44 AM, Philip Martin
> >>> <philip.martin_at_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?
>
> Very portable, extremely cross-platform,

apr_file_info.h

> does not rely on details of filesystem design at all. :)

When you design a filesystem that doesn't have a db/ directory at all, let me
know.
Received on 2013-08-01 05:38:52 CEST

This is an archived mail posted to the Subversion Dev mailing list.