[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Derek Wallace <Derek.Wallace_at_intunenetworks.com>
Date: Thu, 19 Apr 2012 11:47:31 +0000

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:codematters_at_ntlworld.com] On Behalf Of Philip Martin
Sent: 19 April 2012 10:47
To: Derek Wallace
Cc: users_at_subversion.apache.org
Subject: 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
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.
Received on 2012-04-19 13:48:08 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.