Derek Wallace <derek.wall...@intunenetworks.com> writes: > WC/data/folder1/folder11 > WC/data/folder2/folder22 > > A user could have 2 shells open, cd to folder11 and folder22 respectively. > Then at the same time run svn commands (commits, updates, switches). > > > Now that we have upgraded to SVN 1.7 we are regularly getting sqlite locked > error messages. > svn: E200033: sqlite: database is locked > We suspect it is because we are doing concurrent svn commands like the above. > > The consequence of this is that we must run svn cleanup , ususally from the > root checkout. > Our WC is very large and this usually takes a long time. > > > Can you clarify if SVN 1.7 does not support concurrent svn commands within a > WC.
There is a change between 1.6 and 1.7. In 1.6 when one runs svn up WC/data/folder1/folder11 then 1.6 takes a non-recursive lock on folder1 and a recursive lock on folder11. This locking allows the update to delete folder11 which requires modifying the metadata for folder1. However if one runs cd WC/data/folder1/folder11 svn up with 1.6 then only the recursive lock on folder11 is taken. The consequence of not locking folder1 is that if the update is one that should delete folder11 then the update will not do the delete; this can be viewed as a bug or a feature. In 1.7 both commands will lock the tree from folder1 which means that the update will always be able to delete folder11. This can be viewed as fixing a bug or removing a feature. The net result is that 1.6 doesn't allow svn up A/B/X svn up A/B/Y in parallel but does allow cd A/B/X ; svn up cd A/B/Y ; svn up in parallel but at the cost of not allowing cd A/B/X ; svn up to delete A/B/X. 1.7 doesn't allow cd A/B/X ; svn up cd A/B/Y ; svn up in parallel but does allow cd A/B/X ; svn up to delete A/B/X. Both 1.6 and 1.7 allow svn up A/X/Y svn up A/P/Q in parallel. -- Philip
