Ben Collins-Sussman wrote:
>
> On Oct 12, 2004, at 4:52 PM, Greg Hudson wrote:
>
>> I've discussed most of these with Ben and others on IRC, but that's
>> not the proper forum for resolving contentious issues.
>
>
> Thanks for the great feedback, Greg.
>
>>
>> Issue #1: Should "svn lock" implicitly include "svn update"?
>>
>> 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
>> schizoprenic.
>
>
> To whom? :-)
>
>>
>> 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.
>>
>
> To the seasoned unix crowd, I suppose that defining 'lock' to do two
> things contradicts the "lots of small tools" unix philosophy. But to
> the non-techie being forced to use version control, I'm not sure it
> would create confusion.
>
> My ultimate goal is to help users working in the 100% locking
> environment, where everything is read-only and has the 'svn:lock'
> property attached. I guess that such a user needs to learn about 'svn
> update' no matter what... so if 'svn lock' tells them to run 'svn up',
> that's fine. What's *not* okay is 'svn lock' saying 'error, file is
> out-of-date'. The phrase 'out-of-date' is too lingoey.
Sure, but that's not a problem that's unique to the proposed 'svn lock'
command, we have that issue all over the place. Perhaps the client
should catch the SVN_ERR_RA_OUT_OF_DATE error and wrap it in a 'try
running svn update and doing that again' kind of message.
>>
>> 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".
>
>
> I'm fine with this. Maybe 'svn info' just prints extra lock-token info
> if the wc target happens to have a lock-token attached to it? If this
> were the case, I'd want 'svn info' to be able to operate on URLs as well
> (which has been requested before, I think). People need to be able to
> find out who/when/why a repository file was locked... without a working
> copy.
+1, to both including this inforation in 'svn info' and making 'svn
info' work on URLs.
-garrett
---------------------------------------------------------------------
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:52:40 2004