Philip Martin wrote:
>Branko ÄŒibej <brane@xbc.nu> writes:
>
>
>
>>I'm trying think of a good reason why we'd support any kind of
>>concurrent operation in the WC. If we just serialised everything, "svn
>>st" and friends could do this cleanup themselves.
>>
>>
>
>How about a GUI that runs status periodically (or in response to some
>sort of filesystem notification system), that could cause concurrent
>operation with some other process running, say, update. If status
>takes a write lock the update might fail with an "already locked"
>error, but when the user investigated there would be no lock.
>
>
If status takes a read lock and update /doesn't/ fail with "already
locked", then status might die due to reading half-baked data that
update hadn't finished yet. You can't have a reader and a writer in the
same WC at the same time, you can only have multiple readers.
Now I'll admit that if we serialize all access to the WC, then your
scenario with two statuses instead of a status and an update is valid.
However, I think that being able to automatically fix timestamps (and
other WC bogosities, such as leftover files in .svn/tmp) is more
important than running two statuses in parallel. Especially as you can
make the window for lock collision narrower by running "svn st -N" (and
I hope that locks only one directory, not the whole tree).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 23 18:33:11 2004