Re: [RFC] Revision property caching

[Branko Čibej <br...@wandisco.com>]

[Note: I'd like to split this into two threads, one about revprop
caching and another about named atomics]

On 20.08.2014 13:21, Evgeny Kotkov wrote:
> We (Sergey Raevskiy <se...@visualsvn.com> and I) had some time to
> examine the revision property caching feature, and there are some conclusions
> that we would like to share.  In brief, there are certain conditions when this
> feature can actually *wreak havoc* in terms of the repository consistency and
> possible corruptions.  This applies to both Subversion trunk@1618912 and to
> the released Subversion 1.8.10.

[...]

I haven't looked at the implementation, but if your description is
correct, then we're definitely in trouble.

I would have expected that the unversioned-metadata (i.e., currently
only revprop) generation would always be updated regardless of cache
settings, and never be cached. I presume changing the implementation to
behave this way would fix the problem?

And by all means, do commit your failing test case.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane@wandisco.com

Re: [RFC] Revision property caching

[Evgeny Kotkov <ev...@visualsvn.com>]

> [...]
>
> I haven't looked at the implementation, but if your description is correct,
> then we're definitely in trouble.
>
> I would have expected that the unversioned-metadata (i.e., currently only
> revprop) generation would always be updated regardless of cache settings,
> and never be cached. I presume changing the implementation to behave this
> way would fix the problem?

If you mean that we could entirely stop sharing the revprop generation across
multiple processes, it would probably work.

However, I am not entirely sure what was the reasoning behind that kind of
sharing.  If this shared memory thing was an attempt to get rid of the file
parsing overhead, then I would say it is a good idea to choose correctness
in favor of an optimization that breaks things in half of the cases.  But
there might be more to it.

> And by all means, do commit your failing test case.

Done in r1619105.


Regards,
Evgeny Kotkov