Branko Čibej wrote on Mon, Oct 15, 2012 at 23:51:43 -0400: > On 15.10.2012 17:14, Stefan Fuhrmann wrote: > > However, if you have a long-running process like a server, that race > > condition extends now extends over its whole lifetime. I.e. once a > > revprop got read, any change to its value by a pre-1.8 tool may never > > get detected. > > Ouch. This seems wrong. I'd understand a design like this if the > long-running server were the only process accessing the repository, but > that has never been the case in Subversion. In this case, a cache that > can't detect out-of-band changes to the canonical dataset isn't very useful.
Another questionable part of the revprop cache: the ATOMIC_REVPROP_TIMEOUT mechanism in fs_fs.c. (Basically, the code assumes that if another process is rewriting a revprops file, it will always finish within 10 seconds.) 1. It's not documented. (And by that I mean a few paragraphs explaining the algorithm; not docstrings to individual functions, nor documentation of the on-disk format.) 2. It's another instance of breaking FSFS discipline --- if you do something that we think is very rare, your filesystem's behaviour may lose that 'correctness' property. FSFS does not have "correctness except in rare situations" anywhere else --- and 1.6 and 1.7 features had taken some trouble to make sure that had remained the case. The problem raised earlier in this thread is that a 1.8 server might not notice changes made by a 1.7 svnadmin. The problem I have in mind here is that if a writer _does_ happen to take more than 10 seconds, the first process will miss the second process's changes. In short, I believe the FSFS code in 1.8.x sacrifices Subversion's unconditional correctness promises on the altar of performance.
