Stefan Sperling <s...@elego.de> writes:

> Of course, this would require 'svn status' to obtain a write lock on wc.db.
> The status operation must not hold a write lock during regular operation
> because doing so prevents concurrent read access by other clients.
> To keep the time window where the write lock is held as small as possible,
> we could collect a list of affected files during the status run while
> a read-lock is held and update timestamps after the status run for those
> affected files which still have the same timestamp they had during the run.
That might cause problems for multi-threaded GUIs.  If one thread is
running status to update the display it could cause another thread
attempting update to fail because status has a lock.  So a GUI might
want to be able to force status to remain read-only.  Which means the
GUI has to repair timestamps some other way: by running cleanup at
intervals say and being aware that the wc is locked.

-- 
Philip

Reply via email to