[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: Ulrich Eckhardt <ulrich.eckhardt_at_dominolaser.com>
Date: Thu, 19 Apr 2012 11:36:36 +0200

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!

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.
Received on 2012-04-19 11:37:22 CEST

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