On Fri, Apr 20, 2012 at 11:59:32AM +0100, Philip Martin wrote:
> Stefan Sperling <stsp_at_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.
We can grant control over this at the API level via, say, a new boolean
parameter 'fix_timestamps' in svn_client_status(). We'd probably need
this anyway to provide the current behaviour in backwards-compat APIs.
If the GUI application has a choice in the matter, by allowing or
disallowing a status run to update timestamps, it can synchronise
its own threads accordingly.
I'm fine with bothering client developers with this little detail.
I object to bothering end users with it unless there is no other way.
You're not arguing about inter-client effects, right? I.e. a GUI
client trying to update its icons while a command line client 'svn
status' run is updating timestamps? This situation isn't much different
to a command line client performing a concurrent update or commit, which
GUIs need to deal with anyway.
Received on 2012-04-20 13:16:56 CEST