On Wed, Feb 22, 2012 at 4:25 AM, Philip Martin <philip.mar...@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/
