Re: Svn17: concurrent commits in differnt parts of your WC

Derek Wallace <Derek.Wallace_at_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