> We (Sergey Raevskiy <sergey.raevs...@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 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. Here is a quick explanation. Whenever a pre-1.8 binary changes a revision property, it knows nothing about our shared memory and about the existence of the 'db/revprop-generation' file [1]. A revision property change goes just to disk. It does not have any ways of getting into the cache of another process (i.e bumping the revprop generation / accessing the corresponding shared memory); as a consequence, we are left open to a huge amount of unwanted and erroneous behavior I was talking about in my previous e-mail. I did not really had time to think about fixing this, but, hopefully, I will be able to do this in the nearby time. [1] http://svn.apache.org/r1331763 Regards, Evgeny Kotkov
