I have plenty of real-world experience - and I detest locks. The primary
use of locks that I have seen is to try to enforce some rules in a
development process which lacks organization or communication, and/or to
accomidate for code which was badly designed.
In a good development process, you should decouple the features being
developed - this means that individual groups have sets of files which
they are working with. If more than one developer (or more than one
group if you are pair-programming) is working on files, they should
discuss the changes with the other people developing around those files.
For CVS, I've never needed tool integration. When I'm finished making
changes, I review my changes and submit them. Tools which require
locking also begin to require integration into the development tools, as
a user must 'lock' a file before being allowed to edit it.
I've "deadlocked" more times with other developers when I started my
work updating some code, they started their work updating the headers,
and we wound up needing each-other's files for our work. What do I do in
this situation? I'm forced to diff the changes I've made, revert, _wait_
for their work to finish, check out the new files, and apply my patch.
If multiple people are editing a single binary file at one time, they
should be coordinating their work or working _together_.
Locks are only really useful as advisory notices, and then because they
become a communication mechanism that someone else is doing work close
to yours (and that you should probably talk to them _immediately_).
Perforce will do this for you, but most of the integrated environments I
have seen it plug into will not display the message, negating even that
benefit.
(Takes deep breaths)
-David Waite
Mike Wohlgemuth wrote:
>On Fri, 2002-08-02 at 18:33, Jim Blandy wrote:
>
>
>>I'd like to hear more about people's real-life situations, more at the
>>``project manager looking for good working procedures'' level, and
>>less at the ``Subversion implementor'' level. Karl's post about how
>>RCS locks behave with real people going on vacation is at the right
>>level. Bill Tutt hinted at more restrictive applications --- it would
>>be great to hear the whole story about those.
>>
>>
>
>I'm probably a little short on the real world experience compared to
>most people here, but here is what keeps bugging me about this
>discussion:
>
>Anyone that is discussing hard locks (where only an admin or the user
>with the lock can release it) in the same breath says there needs to be
>a way for a user to override this and check in code that someone else
>has locked. So it really seems to me that all locks would be advisory
>in nature, and what we're really discussing is how many extra command
>line options it takes to override a lock. It seems that any sort of
>locking should require some sort of --force option in order to break
>someone else's lock, even if it is just advisory in nature, just so a
>user is forced to acknowledge that "I am aware that someone else has an
>interest in me not changing this file, but my interest in changing it
>overrides that". I guess I just find it hard to see how hard locks that
>can be overridden are any different than advisory locks, or how they do
>anything to ease the mind of someone that thinks hard locks are a good
>thing in the first place. Whatever sense of security they get out of
>this scheme seems somewhat false, and I'm not sure how much Subversion
>should contribute to this false sense of security.
>
>Woogie
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 19:37:32 2002