Edward Harvey wrote:
>> Ahh, but the question then becomes - how is it helpful when a
>> file shows as unlocked in my local cache and does not say
>> that it needs a lock?
>
> I might be misunderstanding your question, but I think you're talking
> about locks that are not locally known, because there hasn't been a
> recent enough update, right?
>
> At first pass, in order to have any benefit you have to perform an
> update. But it's still an improvement, because right now the
> information isn't shown, *even if* you perform an update.
But then the problem is that a user could always assume that a file
without needs-lock is one that could be edited/updated without locking
and thus would not have a lock.
In this new way, one would have to try to do an update before starting
to edit a file - but that would not be enough, since while editing someone
could then lock the file (and add the needs-lock attribute) so the only
safe way to edit a file would be to always lock a file. Thus, in a repository
with such rules, all files would need to be treated as needing to be locked
before editing. There is no other way to fix the race condition since
non-locked editing will never be an atomic operation. (It is the lock that
makes it somewhat atomic... at least to all other potential editors)
> In the future, I would like to see a few improvements to this, but take
> one step at a time and not right now. For example, since the local
> cache of remote lock info describes the repository files and not
> necessarily the local files, it is actually safe to update the local
> cache on *either* an update or a status check.
Yes, one could do that - however that would increase the hit on the server
without actually addressing the race condition. I do a "svn up" or "svn status"
and then a few moments later, someone else locks a file. In the mean time
I just go an edit a file that is assumed to be concurrently editable (does
not have needs-lock) and still end up being frozen out due to the fact that
is now is locked/does need a lock.
> So it then becomes safe to perform a periodic status check silently,
> which would ensure that you always have lock info as recent as n
> minutes. With no risk to anything else you might be doing.
Well, sort of - since needs-lock actually does affect your local work
as it would need to somehow signal you not to make changes (set R-O on
the file) and you may already be making the changes.
The fundamental problem is that there is a race condition here and the
only solution to the problem is to have pre-defined that a file is of
the needs-lock variety before anyone would want to edit the file such
that anyone who does would end up obtaining the lock. Without this you
get the same race and thus have only increased the frustration levels
and confusion with the system.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 1 04:43:24 2006