On 22.08.2014 01:39, Evgeny Kotkov wrote:
>> We (Sergey Raevskiy <sergey.raevskiy_at_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_at_1618912 and to
>> the released Subversion 1.8.10.
> I had some time to think about this topic, and, unfortunately there is more to
> it. If I am not mistaken, the way we currently do the revision property caching
> has no idea of backward compatibility. Apart from the problem with the mixed
> caching configurations in 1.8, the same also applies to a situation with *any*
> pre-1.8 process (mod_dav_svn, svnadmin, svnserve, svn) changing the revision
> properties that are also being cached by a 1.8 process.
I pointed this out here in Sheffield yesterday when I proposed that we
just rip out revprop caching from 1.8 and trunk, because there's no way
to make it work for the kind of configurations that would need it most
(i.e., large installations with multiple servers and load balancing).
There are just too many edge cases to cover.
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
Received on 2014-08-22 11:02:21 CEST