> 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.
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
Received on 2014-08-22 02:40:28 CEST