Greg Hudson <ghudson@MIT.EDU> writes:
> 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 agree with Greg. Another argument against implicit updates is that
lock would need to provide a --diff3-cmd option, and a user who
routinely uses --diff3-cmd on update may forget that it needs to be
used on lock as well.
> 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?
I agree again. It's not clear from the functional spec whether a lock
continues to exist in the database once it's released/broken. I
assume it gets deleted (although I suppose it might get moved from an
active to an inactive list) in which case the locks are transient and
I'm not keen on forcing users to supply log messages for transient
objects.
> 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.
* Provide a .subversion/config default-lock-message that gets used
if neither -m nor -F is used. Then the user can decide whether
they get asked or not.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 00:11:11 2004