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

Re: Issue #4162: make svn status fix timestamp mismatches in meta-data

From: Branko Čibej <brane_at_wandisco.com>
Date: Mon, 23 Jun 2014 11:56:07 +0200

On 23.06.2014 11:43, Julian Foad wrote:
> Branko Čibej wrote:
>> Bert Huijben wrote:
>>> Changing the recorded timestamps would require obtaining a write lock while
>>> performing a status walk... which is a breaking change for any client that
>>> wants to do things concurrently. -1 on 'just doing it' There is a good reason
>>> the current code only updates timestamps when it has a write lock. Otherwise
>>> it would break concurrent operations.
>> I absolutely agree. 'svn status' has never write-locked the working
>> copy. There are clients out there that rely on this documented fact.
>> One of them is TortoiseSVN.
> I don't dispute that, but there seems to be an assumption there that if it takes out a lock on this metadata then that lock will necessarily have to be "the [present] WC write lock" which will therefore block operations such as 'update'. Is it inconceivable that some different level, granularity or kind of locking strategy could be used?

We already have fine-grained locking on the WC: we lock subtrees of the
working copy, not the whole working copy. One can perform an update on
one subtree and status on another subtree, in parallel, as long as the
subtrees are disjunct; and the locks themselves are multiple-reader,

Inventing more fine-grained locking is of course possible, but increases
the problem of avoiding deadlocks quite out of proportion to the benefit

-- Brane

Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-06-23 11:56:40 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.