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

Re: [RFC] Revision property caching and named atomics

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 22 Aug 2014 10:01:51 +0100

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.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com
Received on 2014-08-22 11:02:21 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.