You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2005/04/09 07:12:13 UTC
Lock comment editing UI {was: Re: "svn lock" crashes if editor exits
without saving a lock message]
On Fri, 8 Apr 2005, Philip Martin wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
>
> > On Fri, 8 Apr 2005, Philip Martin wrote:
> >
> >> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
> >>
> >> >> not even any indication that I should write a log message.
> >> >>
> >> > Same applies for propedit.
> >>
> >> Huh? Propedit doesn't use a log message.
> >>
> > Neither does lock, it uses a lock comment;)
>
> Again huh? Propedit doesn't pop up a blank editor.
>
If the prop value is empty, it does... But let's stop this ping-pong game
before it degenerates. I wouldn't object to it.
Anyone think this is important enough to implement?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by John Szakmeister <jo...@szakmeister.net>.
On Sunday 10 April 2005 11:55, 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, I'd like to see it have the same format as the log
> > message.
>
> 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.
Now that I've found out that locks aren't all acquired atomically, I'm
inclined to agree. As long as there is a way to set a comment and
enforce it (via a hook script or something), then I think most the people
that I know using Subversion in the work place will be happy.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by John Szakmeister <jo...@szakmeister.net>.
On Sunday 10 April 2005 18:46, Julian Foad wrote:
> John Szakmeister wrote:
> > 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 unwanted.
> >
> > 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 do. Where I worked for several years we used MS SourceSafe with
> reserved checkouts for all files (on the theory that it was easier for
> the other developers not to have to deal with merges). There were
> about four developers in the team, usually working on different parts
> of the software, but of course occasionally our changes would overlap
> in one or more files. Whenever I wanted to edit a file, if I thought
> the others were unlikely to be (now or soon) working on it, I just
> checked it out (i.e. locked it), without communicating any message. If
> I thought one of them was likely to need it before I would be finished
> with it, then I swivelled my chair and consulted them, and then decided
> whether to check it out, or to wait for them to do their work on it
> first, or to make my (unreserved) local copy writable and start working
> on it and merge my changes in later.
>
> There were occasions when leaving a lock message would have been
> useful, maybe once in every few months, but on a daily basis I would
> lock ("check out") several files without having anything useful to say
> about the fact except the obvious "I'm working on these." The locks
> only got in the way occasionally, when a developer had forgotten about
> them or the work was taking longer than expected, and then the question
> I really needed to ask was not "Why did you take out this lock?" but
> "Have you finished with this, forgotten about it, or what?" which could
> not have been answered in advance in a lock comment.
>
> Of course there are other working environments - like those where the
> developers do not have easy communication among themselves - where the
> working style would be different, but the above is my experience and I
> have no reason to think that it is uncommon.
>
> Another relevant point: In a commit, all the files involved are in a
> single group, and the log message automatically applies to the whole
> group. That's great. With locking, the developer will typically lock
> one file, start changing it, then realise that another file needs to be
> part of the same change, and lock and change that second file, and so
> on, ending up with a set of locked files that is ready to commit as a
> group. There is currently no trivial way of telling "svn lock" to use
> the same lock message that the already-locked file 'foo' has. OK, it's
> easy enough to script, or for a GUI, but the user of plain "svn" is not
> going to want to type the same lock message again and again each time
> he discovers another file that has to become part of the same overall
> change, so that's another reason why, in practice, lock messages will
> be less used than perhaps they would in theory.
>
> I would like to turn the question around and ask if anyone has
> experience of working practices in which people normally use lock
> messages and put something useful (not just "I'm working on this file")
> in them.
Thank you for that explanation Julian. Not that I'm casting doubt on
anyone's experiences, I just wanted to make sure that it was more than
speculation. But it sounds like it's well founded with empirical
evidence to back it up... the best kind. :-) I have no problem with
having no lock message as the default then. After thinking about it
more, and reviewing some notes I've taken about other people's use of
Subversion, you're absolutely right... the one question they really
wanted answer was "Are you finished with this yet?", and "Why is this
change taking so long?"
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by "Brian W. Fitzpatrick" <fi...@collab.net>.
On Mon, 2005-04-11 at 08:12 -0500, C. Michael Pilato wrote:
> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
>
> > Since we don't seem to agree about the message template, I think it is
> > best to just drop this editor stuff altogether for 1.2 and reintroduce it
> > in 1.3 if people want it. Ofcourse, -m and -F would be available.
> >
> > Comments?
>
> +1
+1 here too.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by "C. Michael Pilato" <cm...@collab.net>.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> Since we don't seem to agree about the message template, I think it is
> best to just drop this editor stuff altogether for 1.2 and reintroduce it
> in 1.3 if people want it. Ofcourse, -m and -F would be available.
>
> Comments?
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 11, 2005, at 2:12 AM, Peter N. Lundblad wrote:
> On Sun, 10 Apr 2005, Julian Foad wrote:
>
> ..
>> There were occasions when leaving a lock message would have been
>> useful, maybe
>> once in every few months, but on a daily basis I would lock ("check
>> out")
>> several files without having anything useful to say about the fact
>> except the
>> obvious "I'm working on these." The locks only got in the way
>> occasionally,
>> when a developer had forgotten about them or the work was taking
>> longer than
>> expected, and then the question I really needed to ask was not "Why
>> did you
>> take out this lock?" but "Have you finished with this, forgotten
>> about it, or
>> what?" which could not have been answered in advance in a lock
>> comment.
>>
> This was a nice explanaition, Julian, and having worked like this
> myself,
> I agree. What I implemented in the cmdline client was what I thought
> was
> concensus (since it is in the UI spec).
>
> It now seems like many people want the editor not to be invoked, at
> least
> not by default. This seems reasonable to me. It is easier to add it
> later
> than back it out when 1.2 is released. I see little point in a cmdline
> switch to run the editor (as ghudson proposed), since the user can as
> easily run the editor herself. A config option would make sense.
>
> Since we don't seem to agree about the message template, I think it is
> best to just drop this editor stuff altogether for 1.2 and reintroduce
> it
> in 1.3 if people want it. Ofcourse, -m and -F would be available.
>
> Comments?
>
If there's a consensus on this, then I'm fine with changing this.
Let's make sure we update our func-spec/ui-spec too.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sun, 10 Apr 2005, Julian Foad wrote:
..
> There were occasions when leaving a lock message would have been
> useful, maybe
> once in every few months, but on a daily basis I would lock ("check out")
> several files without having anything useful to say about the fact except the
> obvious "I'm working on these." The locks only got in the way occasionally,
> when a developer had forgotten about them or the work was taking longer than
> expected, and then the question I really needed to ask was not "Why did you
> take out this lock?" but "Have you finished with this, forgotten about it, or
> what?" which could not have been answered in advance in a lock comment.
>
This was a nice explanaition, Julian, and having worked like this myself,
I agree. What I implemented in the cmdline client was what I thought was
concensus (since it is in the UI spec).
It now seems like many people want the editor not to be invoked, at least
not by default. This seems reasonable to me. It is easier to add it later
than back it out when 1.2 is released. I see little point in a cmdline
switch to run the editor (as ghudson proposed), since the user can as
easily run the editor herself. A config option would make sense.
Since we don't seem to agree about the message template, I think it is
best to just drop this editor stuff altogether for 1.2 and reintroduce it
in 1.3 if people want it. Ofcourse, -m and -F would be available.
Comments?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by Julian Foad <ju...@btopenworld.com>.
John Szakmeister wrote:
> 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
>>unwanted.
>
> 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 do. Where I worked for several years we used MS SourceSafe with reserved
checkouts for all files (on the theory that it was easier for the other
developers not to have to deal with merges). There were about four developers
in the team, usually working on different parts of the software, but of course
occasionally our changes would overlap in one or more files. Whenever I wanted
to edit a file, if I thought the others were unlikely to be (now or soon)
working on it, I just checked it out (i.e. locked it), without communicating
any message. If I thought one of them was likely to need it before I would be
finished with it, then I swivelled my chair and consulted them, and then
decided whether to check it out, or to wait for them to do their work on it
first, or to make my (unreserved) local copy writable and start working on it
and merge my changes in later.
There were occasions when leaving a lock message would have been useful, maybe
once in every few months, but on a daily basis I would lock ("check out")
several files without having anything useful to say about the fact except the
obvious "I'm working on these." The locks only got in the way occasionally,
when a developer had forgotten about them or the work was taking longer than
expected, and then the question I really needed to ask was not "Why did you
take out this lock?" but "Have you finished with this, forgotten about it, or
what?" which could not have been answered in advance in a lock comment.
Of course there are other working environments - like those where the
developers do not have easy communication among themselves - where the working
style would be different, but the above is my experience and I have no reason
to think that it is uncommon.
Another relevant point: In a commit, all the files involved are in a single
group, and the log message automatically applies to the whole group. That's
great. With locking, the developer will typically lock one file, start
changing it, then realise that another file needs to be part of the same
change, and lock and change that second file, and so on, ending up with a set
of locked files that is ready to commit as a group. There is currently no
trivial way of telling "svn lock" to use the same lock message that the
already-locked file 'foo' has. OK, it's easy enough to script, or for a GUI,
but the user of plain "svn" is not going to want to type the same lock message
again and again each time he discovers another file that has to become part of
the same overall change, so that's another reason why, in practice, lock
messages will be less used than perhaps they would in theory.
I would like to turn the question around and ask if anyone has experience of
working practices in which people normally use lock messages and put something
useful (not just "I'm working on this file") in them.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by John Szakmeister <jo...@szakmeister.net>.
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
> unwanted.
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.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> It seems reasonable for the lock message template to have the same
> format as the commit message template.
... but it also seems reasonable for it to differ.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by Julian Foad <ju...@btopenworld.com>.
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 unwanted.
>>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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor
exits without saving a lock message]
Posted by Greg Hudson <gh...@MIT.EDU>.
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,
> I'd like to see it have the same format as the log message.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Lock comment editing UI {was: Re: "svn lock" crashes if editor exits without saving a lock message]
Posted by John Szakmeister <jo...@szakmeister.net>.
On Saturday 09 April 2005 03:12, Peter N. Lundblad wrote:
> On Fri, 8 Apr 2005, Philip Martin wrote:
> > "Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > > On Fri, 8 Apr 2005, Philip Martin wrote:
> > >> "Peter N. Lundblad" <pe...@famlundblad.se> writes:
> > >> >> not even any indication that I should write a log message.
> > >> >
> > >> > Same applies for propedit.
> > >>
> > >> Huh? Propedit doesn't use a log message.
> > >
> > > Neither does lock, it uses a lock comment;)
> >
> > Again huh? Propedit doesn't pop up a blank editor.
>
> If the prop value is empty, it does... But let's stop this ping-pong
> game before it degenerates. I wouldn't object to it.
>
> Anyone think this is important enough to implement?
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,
I'd like to see it have the same format as the log message.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org