You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Derek Wallace <De...@intunenetworks.com> on 2012/04/19 10:51:47 UTC
Svn17: concurrent commits in differnt parts of your WC
Hi,
In SVN 1.6 we were able to do concurrent SVN actions in differnet areas of our WC
Example
---------
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.
Thx
Derek
-------------------------------------------------
Derek Wallace,
Director of Release Engineering,
Intune Networks Ltd
Block 9B, Park West Business Park, Nangor Road, Dublin 12, Ireland.
Phone: +353-1-6204737 Fax 353-1-6301914
URL: http://www.intunenetworks.eu
-------------------------------------------------
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.
Re: Svn17: concurrent commits in differnt parts of your WC
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 19.04.2012 10:51, schrieb Derek Wallace:
> In SVN 1.6 we were able to do concurrent SVN actions in differnet areas of our WC
SVN 1.6 also locked the parent directory, so the different areas had to
be at least two dirs away from each other.
> Example
> ---------
> 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.
In SVN <= 1.6, ever subdir of a working copy was a working copy itself,
so most operations were restricted to just that directory (and to some
extent its parent). Starting with 1.7, the whole working copy has only
only one central place where metadata is stored, and during operations
on that data it must be locked against other accesses. Summary: Yes,
concurrent svn commands will fail.
> 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.
I suspect that you actually just checked out the root folder of the
repository into one gigantic working copy. Don't do that. Instead, just
check out the parts that you actually need. This also makes it much
easier to create another WC to do experiments on a project therein by
just copying it.
BTW: In 1.6, there was the same problem when the separate dirs were not
sufficiently far apart. SVN then said the WC was locked and suggested to
run cleanup. However, running cleanup isn't actually necessary. The
assumption behind the error message was that nobody would run commands
concurrently, so the conclusion of finding the lock was that there must
have been a command that was interrupted before it cleaned up its locks.
This isn't the case though, the other command will run to an end and
then clean up its locks, and then you can continue working on it without
any cleanup!
Greetings from Hamburg!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
Re: Svn17: concurrent commits in differnt parts of your WC
Posted by Philip Martin <ph...@wandisco.com>.
Derek Wallace <De...@intunenetworks.com> writes:
> 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?
When you run "cd A/B/X ; svn up" X will get updated to HEAD. If X is no
longer present in HEAD because it has been deleted then the update could
attempt to remove A/B/X from the working copy just like any other
deleted directory. 1.6 doesn't attempt the delete partly because A/B is
not locked.
> 2. why does this work in svn 1.7.
It also works in 1.6.
> Will they both not put a lock in the .svn folder beside A.
>
> svn up A/X/Y
> svn up A/P/Q
When you run "svn up A/X/Y" Y gets locked because it is going to change,
and X gets locked because it was required in 1.6 since deleting Y would
modify X/.svn/entries. 'A' doesn't change so doesn't get locked.
[Although 1.7 currently locks X it's possible that this is simply
inherited from 1.6 and it may be possible to change it in the future.]
--
Philip
RE: Svn17: concurrent commits in differnt parts of your WC
Posted by Derek Wallace <De...@intunenetworks.com>.
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@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 <De...@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.
Re: Svn17: concurrent commits in differnt parts of your WC
Posted by Philip Martin <ph...@wandisco.com>.
Derek Wallace <De...@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