Philip Martin <philip.mar...@wandisco.com> writes: > svn_fs_txn_root() calls svn_fs_fs__initialize_txn_caches() and if that > detects concurrent transactions it sets ffd->txn_dir_cache to NULL so > the out-of-date cache doesn't get used and the property change on disk > makes it into the revision.
The txn_dir_cache gets cleared when the pool associated with the txn_root is cleared and so the problem only occurs when the server holds a root open for long enough: the txn_root used to build the transaction has to remain open when the transaction is committed. svnserve and ra_local both do this and show the problem but for apache/mod_dav_svn it depends on exactly when apache clears the request pool between requests. 1. client sends MKCOL 2. apache process MKCOL and populates txn_dir_cache 3. apache sends MKCOL response 4. apache clears MKCOL request pool 5. client sends MERGE 6. apache process MERGE 5 can happen before 4 since two processes are involved but can 6 happen before 4? I've not seen it happen with the worker MPM but I'm not familiar with all the MPMs. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
