On 01.08.2013 05:38, Daniel Shahaf wrote:
> 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,
>> 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
I was talking about file systems, not Subversion's versioned filesystem
backend. If you look closely at the APR implementation, you'll find that
the "inode number" is not guaranteed to be persistent on Windows. It all
depends on which file system you happen to be using.
Not to mention that inodes can be reused. Do you really want to design
that kind of Heisenbug?
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
Received on 2013-08-01 07:04:54 CEST