I just read through the locking functional reqs and UI doc. I'll add my $.02
to Greg's comments and add my own comments regarding the UI...
--On Tuesday, October 12, 2004 4:52 PM -0400 Greg Hudson <ghudson@MIT.EDU>
wrote:
> 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.)
Absolutely agreed that 'lock' should not touch the contents of the file.
> Issue #2: Should "svn update" resolve hijacks interactively?
>...
> I believe this is a total non-starter. It has the same problems as
Yah. Ickiness abounds.
I'm wondering if there is a way for 'svn resolved' to somehow help out. What
are the drawbacks of adopting the '.mine' and '.rXXXX' model? I think having
consistency might be beneficial here.
> Issue #3: Should lock messages be required?
> ...
> 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.
I view the $EDITOR being brought up with either -m or -F as options as my
preference. There should be an ability to have a lock message, as in "I'm
adding Section 7.9. ETA: 1 hour." Lock messages would be wonderful!
While not a UI issue per se, here's a question that I don't think I've
necessarily seen answered yet, but would the acquisition or release of a lock
bump the repository revision number? (If we're adding svn:lock as a property
on the resource, my hunch is that the global revnum is going to have to
change.)
> Issue #4: "svn lockinfo" command?
> ...
> client-local operation and lock information has to be fetched from the
> server, but perhaps this could be an option to "svn info".
Agreed. Add something to 'svn info'.
On to my own comments:
Issue #5: Should 'svn commit' release a lock?
I don't think so. I think that if a lock is explicitly requested, then it
needs to (by default) be explicitly released. I'd reverse the commit behavior
and have '--release-lock' be an option: the default should be to keep the lock.
Here's a use case that I think is more common than not: I lock a file, I want
to make some changes to the file. It's 5pm and I want to go home for the day,
so I commit my changes so I can checkpoint my work (after all, that's the
point of a SCM). By checking it in, I can let other people view my progress,
but I still want to reflect to everyone else that I still have the lock on the
file. (That is, if you break or steal it, be aware that I was doing something
with it.)
I just don't think it's intuitive for 'svn commit' to release the lock when I
explicitly requested it with 'svn lock.' 'svn unlock' should be the desired
usage path we lead users towards. (UIs like TSVN or whatnot can have a
checkbox for allowing the user to release the lock on commit. I'm only
concerned about what our command-line GUI does.)
Issue #6: How would the hook scripts know that the lock is already locked?
This seems to me to be a separate case for a 'force' set of hook scripts or a
flag into the scripts to indicate if the lock was already held. (Pass in
LOCK_OWNER?) For example, I wouldn't care about an unlock where the owner is
doing the unlocking. However, I'd very much care about the case where the
unlocking is done by someone who isn't the owner. I'd personally want an
email sent in that case. And, I'm not at all clear how the hook scripts would
know the difference from the locking-ui.txt.
Looks great. =) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 08:30:18 2004