There has been so much activity, it is hard to know what to quote, or
where to begin. I am just going to start with Greg's original email.
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".
> Issue #2: Should "svn update" resolve hijacks interactively?
> When people or their tools fail to play nicely, Subversion will find
> itself in the situation of having to resolve conflicts in a file which
> (through the svn:lock property) has been tagged as unmergeable. The
> document suggests resolving this issue by interactively asking the
> user whether to prefer the local edit or the repository edit, and
> leaving the other behind in a backup file.
I agree with you. Personally, I did not completely understand why the
existing behavior is not good enough. I think that it should try to
auto-resolve any conflicts and otherwise leave it for the user. If this
can be made better, than make it better for the non-locking scenarios too.
> 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 would not object if lock messages were not required, but I would really
like to see them at least be optional. I think they are a great idea and
can really enhance usability, especially in GUI's. I kind of liked the
idea of being able to have a default lock message in a configuration file.
That seems like it would satisfy power users.
I suppose the lock message could be enforced by a hook script too, so
again, I am more interested in the feature itself than whether it is a
> 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".
It seems like some good ideas have been proposed already. The main thing
is that there has to be a good way to interrogate lock information from
the repository. Would any information be stored in the WC? I think it
would be useful if an svn up brought down the information about what locks
were held. Even though that information could become stale, it could
still be useful to know that a file was locked without contacting the
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Oct 13 15:34:50 2004