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.
> Issue #2: Should "svn update" resolve hijacks interactively?
>
>
> 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.
>
I think I agree... adding interactivity to 'svn up' is going to kill
us. I like your idea of doing a "wussy" merge on 'svn:lock' files in
the case of a hijack -- that is, instead of creating a (C)onflicted
file with three fulltexts, we print a warning and drop the repos file
into a backup. That's sufficiently user-friendly, doesn't necessarily
lose data, and keeps non-techies from having to learn what a conflict
is, or how to deal with it.
> Issue #3: Should lock messages be required?
>
>
> * 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.
I have no real opinion on this issue. What do others think?
>
> 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.
---------------------------------------------------------------------
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:47:36 2004