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