[Michael Sinz]
> In fact, a major reason for locking support is to deal with files
> that do not merge well, for example, jpeg files.
[...]
> The action of obtaining the lock is atomic and prevents multiple
> people from owning it. But the signal/requirement that you need a
> lock is given in a non-atomic fashion. Thus, that signal/flag needs
> to be there for "some time" before the first lock is obtained. The
> reason is that you need all users to know of this fact before you can
> assume that all users will follow the locking protocol.
Both of these statements seem to imply that nobody should ever lock a
file unless svn:needs-lock is already set. (As you say elsewhere,
svn:needs-lock can be set well in advance.) But the rest of your
message indicates that you don't really think that: we agree that there
may be times you do want to lock a file which does not already have the
needs-lock property.
So when I take a lock on a file to prevent others from changing it on
me, what would you say about that? Here are the four possibilities I
can think of:
1) Don't tell any other clients about the locks, even when they ask for
status updates. Let other users waste their time making changes
they will not be able to commit, and may not be able to merge later.
Maybe laugh at them when this happens. This is the status quo.
2) Tell any client that issues a 'svn update' that the file is now
locked by someone else, so the client can advise the user of this
situation (using the read-only bit, or a GUI element, or whatever).
Accept that clients who don't "svn update" very often will sometimes
have out-of-date information, because this is a well-known property
of the entire subversion WC design. Accept that users who don't
"svn update" very often may waste some work, because this is always
true as well.
3) Assume that this situation will never occur - users will never want
to lock a file which is normally mergeable, or if they do, they will
never do it for the reason that their particular edits will make
merges difficult.
4) Redesign svn to push locking notifications asynchronously from
server to client, or manage all state on the server, like p4.
It should be clear that 3 and 4 are not really reasonable, and I favor
2 over 1. Do you favor 1, or something else?
> It is not enough to say that one should always be up-to-date (which
> one normally would be before an edit) since what is being proposed
> here is that when a lock is gotten to somehow set the needs-lock
> property in an atomic way to help protect the other users. This is
> not really possible since the other users may already be in the edit
> phase of their process and do not have a lock since the file was not
> a needs-lock file.
So what do you propose to do instead? I think telling users about
locks that affect their working copies is a _good_ thing, not a _bad_
thing. The race condition does not affect the integrity of the system,
since the server actually enforces the locking. Sending the
information to the client is purely advisory. Do you really think the
status quo is better, where users have no idea they have been wasting
their time until they try to commit?
Received on Mon May 1 23:05:03 2006