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
Received on Mon Apr 11 02:47:42 2005