On Wed, Feb 22, 2012 at 4:25 AM, Philip Martin
<philip.martin_at_wandisco.com> 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.
It seems like the only new negative that using this flag would bring
is that you could not run something like svn log while an svn status
was running. IOW, read operations would block each other. But a
write operation is already blocking all readers. That said, I do not
know how we work internally. Perhaps the lock during update/commit
does not happen until after the status crawl when we are actually
doing the writing? Maybe there is a window when a read operation
would work today?
In practice, many of these operations are already exclusive today.
Maybe we could just make operations like checkout, update, commit,
merge use this exclusive pragma and leave it off the pure read
operations?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-02-22 13:48:54 CET