Thanks for confirming what we suspected, there is a change in SVN behaviour.
Philip, I can follow some of your comments . 1. This comment in parallel but at the cost of not allowing cd A/B/X ; svn up to delete A/B/X. <---- whats this? 2. why does this work in svn 1.7. Will they both not put a lock in the .svn folder beside A. svn up A/X/Y svn up A/P/Q Thx for all your help. Derek -----Original Message----- From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of Philip Martin Sent: 19 April 2012 10:47 To: Derek Wallace Cc: users@subversion.apache.org Subject: Re: Svn17: concurrent commits in differnt parts of your WC 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 IMPORTANT NOTE: The information in this e-mail (and any attachments) is confidential. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient, please notify the sender immediately or telephone: +353 (0)1 6204700. We cannot accept any responsibility for the accuracy or completeness of this message as it has been transmitted over a public network. If you suspect that the message may have been intercepted or amended, please call the sender.
