[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Locking UI comments

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-12 22:52:47 CEST

I've discussed most of these with Ben and others on IRC, but that's
not the proper forum for resolving contentious issues. So, here are
my reactions to notes/locking/locking-ui.txt:

Issue #1: Should "svn lock" implicitly include "svn update"?

The document says yes. I believe that it is not intuitive for the
verb "lock" to include an implicit update, and people may be surprised
by the "helpful" behavior. Instead, I think lock should error out if
the file is not up to date, with the error message instructing the
user to update the file. (I'm fine with an explicit "svn lock
--update" if and only if there is a considered belief that it would be
a real convenience for users.)

As I understand things, Ben's rationale for locking-implicitly-updates
is to mirror the behavior of other version control systems which are
either non-concurrent (VSS) or non-concurrent by default (Clearcase).
(It wouldn't be a very perfect mirror; in those systems, it's not so
much "locking implicitly updates" as "checking out implicitly locks.)
I don't think it's a good idea to model our default behavior after a
non-concurrent version control system; we will wind up looking

If we want to change the verb to "grab" or "reserve", then maybe it
would be okay to perform an implicit update, but I don't see what's
wrong with just erroring out if the file is not up to date.

Issue #2: Should "svn update" resolve hijacks interactively?

When people or their tools fail to play nicely, Subversion will find
itself in the situation of having to resolve conflicts in a file which
(through the svn:lock property) has been tagged as unmergeable. The
document suggests resolving this issue by interactively asking the
user whether to prefer the local edit or the repository edit, and
leaving the other behind in a backup file.

I believe this is a total non-starter. It has the same problems as
setting diff3 to an interactive merge program--the server is sending
data to the client, and is going to time out if the client stops and
waits for user input. The proper answer is to leave behind enough
information in the WC for later resolution, as we do for merge
conflicts now.

Also, the svn command-line client is not designed to be highly
interactive, and bucking that trend lightly will result in serious
usability issues. If there are a thousand hijacks to deal with, are
we going to ask the user a thousand questions? A GUI can (and
probably should) tackle the hijacking issue by asking questions after
the update completes, but our command-line client should punt.

What we can do is alter our behavior on a conflict for a file which
has been tagged with the svn:lock property. Instead of generating a
conflict marker and perhaps attempting a merge, we can leave the local
edit in place, drop the repository edit into a backup file, and warn
the user. I'm not certain whether this is right or not.

Issue #3: Should lock messages be required?

The document says that "svn lock" should pull up an editor and demand
a lock message if the user does not provide one with the -m or -F
option. The implication is that a GUI like tsvn would also request a
lock message whenever the user locks a file (or files, if there's a
way to select a bunch of files and lock them all in one go).

I suspect that many users are either used to or would prefer
environments with no lock messages. If I want to know why Bob locked
a file, I'll ask him, but 95% of the time I'll never need to know, so
why should he write it down each time?

So, here are alternatives I would consider more palatable:

  * Punt on lock messages for the initial implementation.

  * Support lock messages, but only specify them if the user specifies
    a -m or -F option on the "svn lock" command line.

  * Use a file property (either the contents of svn:lock, or a
    separate boolean property) to determine whether the UI should get
    in the user's face about lock messages. Then a project can
    decide, on a per-file basis, whether to require lock messages.

Issue #4: "svn lockinfo" command?

As you all know, I've very keen on keeping our command set small.
"svn lock" and "svn unlock" are pretty much non-negotiable for this
feature, but when we already have "svn status" and "svn info", do we
really need a separate "svn lockinfo"? I realize that svn info is a
client-local operation and lock information has to be fetched from the
server, but perhaps this could be an option to "svn info".

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 12 22:53:51 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.