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,
single-writer.
Inventing more fine-grained locking is of course possible, but increases
the problem of avoiding deadlocks quite out of proportion to the benefit
gained.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-06-23 11:56:40 CEST