[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: script to detect timestamp-mismatches (inefficiency) in (1.7) working copies?

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 20 Apr 2012 13:16:20 +0200

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

This is an archived mail posted to the Subversion Users mailing list.