Situation.
In 1.8, revprop caching only works if *all* processes accessing the
same repository
1. Are located on the same machine.
2. Have revprop caching enabled.
The problem with this is that in 1.8
* we did not mention the restriction in the release notes,
* have no way to detect a violation of that rule,
* ra_local access does not enable it
(e.g. svnsync and svn over file://; svnadmin is fine)
While many setups can be made to work within these restrictions,
the current thinking is that even if we told people what they can do,
they will still do the wrong thing.
Background.
Revprop caches are per-process as the other caches we use.
To detect changes however, we bump a "generation" number
every time we modify any revprop in the repository. That number
is part of the cache key automatically hiding outdated contents.
Access to the generation number must be quick and free of hazards.
Therefore, we keep it in a shared memory segment and use atomic
operations to modify it. This requires all processes writing revprops
to be on the same machine and update the generation info in the
shared memory, i.e. must have revprop caching enabled as soon
as any of them has.
Failure to do so can result in non-atomic revprop changes and
stale revprop contents to be delivered.
Solution.
* Revert r1619413 on /trunk.
* Disable revprop caching on /trunk (ignore the FS config option)
* Propose for 1.8 backport, inform users appropriately upon release
* Open dev branch for revised implementation
* Directly use the generation file instead of the secondary SHM
* Use hash sums stored with the generation number to detect
generation file update hazards.
* Always bump the generation upon revprop change
(even if not cached)
* Disable revprop caching and issue a warning when a 1.8-style
generation file is detected.
* Before writing modified revprops, read them from disk even in
cached mode. That guarantees change API atomicy again.
Remaining restrictions:
* All processes modifying revprops must use 1.9 or later libraries
or revprop caching cannot be used.
* Repositories on network file systems are not strictly supported
(independent restriction due to lack of atomicy guarantees);
shared block devices should be fine, though.
-- Stefan^2.
Received on 2014-08-22 12:51:08 CEST