> 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)
I am not trying to implement any change that would guarantee never a
merge. That has already been done with needs-lock. But the downside of
needs-lock is serialization of developers' work, prohibiting them from
working in parallel, even though most merges are easy and/or automatic.
I am only trying to communicate the presence of a lock to users who
don't own the lock. Because sometimes a person is going to make
extensive changes to a file, which he/she knows will be difficult or
impossible to merge. So the user obtains a lock, indicating that it's
unwise for anyone else to work on it until after the next commit.
> > 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.
That's right. Some servers face the internet with a limited data pipe,
using strong encryption and authentication is a network cost. Those
administrators would not want their users to constantly poll for
updates.
But some servers are internal, at software companies, running a
lightweight protocol such as svnserve. And these can handle excessive
polling with no trouble at all.
The idea of automatic polling is not for everyone, just the ones who
want it.
> > 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.
Good point. But I think that's acceptable behavior. Bear in mind, the
whole read-only bit would be a feature that's disabled by default. So
you would only experience this behavior if you intentionally turned it
on.
> 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
I partially disagree -- Although there is fundamentally a race of who
edits/commits/locks a file first, the needs-lock is not the only
solution.
At one extreme, you don't have any locking at all. People are subject
to races against each other, without knowing what each other are doing.
At the other extreme, every file has needs-lock, which guarantees there
will never be a race. But it also inhibits parallelization of
developers' work. No two people can work on a file at the same time.
Somewhere in between these two extremes, the presence of one user's lock
will be communicated to the other users, but only during update or
status checks. Users are willing to accept that the status might have
changed since the last update, but they're comforted by the fact that
their update was only n minutes ago.
Users are willing to accept that "lock owner" on any given file is only
as accurate as the most recent update. Nobody expects instant updates,
because svn doesn't provide instant updates.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 3 00:33:04 2006