On Sunday 10 April 2005 15:06, Julian Foad wrote:
> Greg Hudson wrote:
> > On Sat, 2005-04-09 at 06:25, John Szakmeister wrote:
> >>I'm all for consistency. To me, locking is almost the same as
> >> committing, in that it involves interaction with the server that is
> >> longer term. So,
> That's an impractical view of the situation. Both persist for a while,
> but commits persist essentially for ever, whereas locks are inherently
> transient, "longer term" than something maybe, but definitely "short
> term" compared to commits. Lock comments are far more likely to be
Is it really? In my eyes, commits and locking serve double duty. Commits
modify the repository, and locks attempt to prevent wasting someone's
time with incompatible changes. But both serve as an indication that
either a change has occurred, or that one is about to occur. While a
lock may be shorter term than a commit, I don't believe we play down the
communication factor because of it.
Personally, I don't have enough experience with version control systems
that implement locking to know what a sound default should be. Do you
have something that you're basing the your opinion on?
> >>I'd like to see it have the same format as the log message.
> It seems reasonable for the lock message template to have the same
> format as the commit message template.
> > Well, I have a rather different view. I'm shocked and dismayed to
> > find out that "svn lock filename" brings up an editor by default. I
> > think most users will view lock comments as an annoyance and will
> > prefer not to use them. "svn lock filename" should just lock the
> > file with no comment, and we should have an explicit flag to bring up
> > an editor to record the comment with. Once we switch to that model,
> > it doesn't matter as much what comes up in the editor window.
> I agree. The old trick of configuring the log message editor to be
> some null command is not feasible because one doesn't normally want to
> disable commit messages as well.
Overall, I'm just concerned about consistency. Subversion's been
extremely consistent about it's interface in the past, and I want to
ensure that it stays that way. I believe it's been extremely valuable in
getting newbies up to speed with version control.
That said, I'm not against reasonable defaults by any means, but I'd
rather we back up the claim that lock comments won't be used, rather than
speculate about it before we change the behavior.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Apr 10 23:47:24 2005