Why do read-only operations still need repository write access?
Certain client operations are “read-only”, like checkouts and updates. From an access-control standpoint, apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function. In particular, the repository responds to many “read-only” operations by comparing two trees. One tree is the usually the HEAD revision, and the other is often a temporary transaction-tree — thus the need for write access.
Certain client operations are “read-only”, like checkouts and updates. From an access-control standpoint, apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function. In particular, the repository responds to many “read-only” operations by comparing two trees. One tree is the usually the HEAD revision, and the other is often a temporary transaction-tree — thus the need for write access. This limitation only applies to the bdb backend; the FSFS backend does not exhibit this behaviour.
Certain client operations are “read-only”, like checkouts and updates. From an access-control standpoint, Apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function. In particular, the repository responds to many “read-only” operations by comparing two trees. One tree is the usually the HEAD revision, and the other is often a temporary transaction-tree — thus the need for write access. This limitation only applies to the Berkeley DB backend; the FSFS backend does not exhibit this behaviour.
Certain client operations are “read-only”, like checkouts and updates. From an access-control standpoint, Apache treats them as such. But libsvn_fs (the repository filesystem API) still has to write temporary data in order to produce tree-deltas. So the process accessing the repository always requires both read and write access to the Berkeley DB files in order to function.
