From: Mark Phippard [mailto:MarkP@softlanding.com]
> Greg Hudson <ghudson@MIT.EDU> wrote on 10/12/2004 04:52:47 PM:
>
>> 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.)
>
> I do not really understand the objections here. If you have to have
an up
> to date file in order to lock it, and we are trying to make this easy
for
> "users", then why shouldn't svn lock update the file automatically?
OK,
> maybe the verb could have been better than "lock", but the people this
> feature is largely being written for are not going to care about that.
At
> a minimum, I think there has to be an option to do the update so that
the
> GUI's that are built can implement it this way. Ideally, I think that
the
> update should be the default, and there should perhaps be an option to
not
> do the update and error out if the file is out of date.
>
> Having not come from a CVS background myself, I wish that the
"checkout"
> verb was still available to mean "get the latest and lock it". In my
> world, that is what we call a "checkout".
I tend to agree. I see that the only reason to avoid combining the two
functions is that the name "svn lock" doesn't advertise that it's
updating the working copy. A better verb could resolve this. How about
"svn claim"? We'd be saying, "Gimme that file. It's mine." This would
be different from "svn update" which just gets the latest copy without
locking.
Then we'd have "svn commit" to send up our changes while retaining the
lock. To commit and release the lock, perhaps "svn release" or "svn
return" or "svn unclaim" or, hmmm... this part still seems a bit
fuzzy...
** One other thing to consider... To what degree to we want our
commands to parallel the locking protocol in WebDAV? I think whatever
choices we make about lock-strategy enforcement need to take a WebDAV
client into account. My guess is that once we support locking, a
certain percentage of the population will start with WebDAV use, and
some of those will graduate to an SVN client. We'll want to make sure
that the transition is not overly difficult from too many differences in
the locking strategy.
--Steve Dwire
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 17:33:48 2004