Mark Phippard <[email protected]> writes:
> On Wed, Feb 22, 2012 at 4:25 AM, Philip Martin
> <[email protected]> wrote:
>> The user has more information than the application can ever have. If
>> the user wants to be able to run two subtree updates in parallel then
>> exlusive locking must not be enabled. If the user wants to run status
>> during an update then exclusive locking must not be enabled.
>
> These scenarios are already changes that SQLite brings us. You cannot
> update two subtrees in parallel today. You cannot run status while an
> update or commit is running. As noted in another thread this week,
> you cannot even run svn log when one of these processes is running.
That's not correct. Start and hold an update:
$ gdb -arg subversion/svn/.libs/lt-svn up wc/A/B/C
(gdb) b update_editor.c:close_directory
(gdb) r
Breakpoint 2 at 0x7ffff78eee2f
Run status:
$ svn st wc
L wc/A/B
! L wc/A/B/C
! L wc/A/B/C/D
Update a different subtree:
$ svn up wc/X/Y/Z
Updating 'wc/X/Y/Z':
A wc/X/Y/Z/Q
Updated to revision 4.
Resume first update:
(gdb) disable 1
(gdb) c
Continuing.
Updated to revision 4.
There are changes in 1.7 that reduce concurrency:
- in 1.7 a work-queue item will prevent status running. in 1.6 status
would run when log files were present.
- during an SQLite write transaction other SQLite read transactions
may block and even timeout, in 1.6 access to non-locked directories
didn't block.
So concurrency is reduced but some concurrent operation still works in
1.7.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
