Hi. First time poster here. My shop is still on CVS so I don't have
any comments on subversion specifically, but I would like to make a
valid argument in support of locking.
political disclaimer: I personally support an optimistic concurrency
model and believe that a good branching/merging approach is better than
locking.
That said, I think that one of the chief criticisms of a locking
approach has recently become almost irrelevant. The biggest gripes I
usually hear about locking are because developer A can't get at the code
they need to finish what they are doing because developer B has it
locked, but either isn't working on it, isn't around, or has been lazy
in unlocking/checking in.
The modern solution is Instant Messaging. Now, regardless of location,
if developer A needs something that developer B, instant messaging makes
it easy to say "hey man, will you unlock file foo.c for me?"
I am not saying that this is the only problem with locking or even
advocating locking. Just that if you do find yourself in a
locking-oriented shop, you can make life much easier for yourself by
getting everyone on IM (preferably internally hosted, encrypted jabber,
but whatever suits your fancy)..
andy.glew@amd.com wrote:
>>Then I nearly wet myself when she replied, "That will be
>>great. Then we can lock all the code to whoever is assigned
>>to work on it." She's not talking
>>about binary files, here. She's talking mergable code.
>>
>>Is it just me, or is this idea absurd?
>>
>>
>
>
>Pretty damned annoying, but not totally absurd.
>The way to get her to see the light is not to
>tell her that she is stupid, but to acknowledge
>the real underlying need, explain how merging
>works 99% of the time, and then show how
>locking is available when there is a problem
>that cannot be solved by merging.
>
>First off, the ammo: all the folks who talk
>about merging, starting off with Berliner's
>CVS paper. Maybe make a list of all the projects
>that use CVS. Here's a start: both AMD and Intel
>use CVS as part of their chip design projects.
>
>Now, the acknowledgement:
>
>When you've made a change C in your workspace,
>you need to integrate it via an algorithm that
>looks something like the following:
>
> checkout tree
> make change C
> loop
> test it
> if tests pass, break loop
> fix
> end loop
> loop
> update from mainline
> test it
> if tests pass
> if there has not been a change
> checkin
> break loop
> fi
> fi
> end loop
>
>You can short-circuit some of these steps,
>but the above is pretty much what you want to do
>if you want to guarantee that only code that
>passes all tests is checked in.
>
>Unfortunately, the above process is
>NOT guaranteed to terminate. In theory, if
>other people were checking in too quickly,
>somebody could remain stuck in the
>update/test loop forever.
>
>But that theoretical event doesn't happen very
>often.
>
>The exclusive lock people say
>
> LOCK
> loop
> update from mainline
> test it
> if tests pass
> if there has not been a change
> checkin
> break loop
> fi
> fi
> end loop
> UNLOCK
>
>The merge people say "just merge"; if you get stuck
>in a loop, raise it at a group meeting and ask
>people to hold off for a while.
>
>Some of the merge people say "just merge without
>testing; test later, and backout broken changes".
>
>The optimistic concurrency people say "try merging
>without a lock; if you get stuck in a loop, then
>get the lock".
>
>I'm one of the optimistic concurrency people,
>but I've only seen two or three situations
>in 2 decades where a lock was needed.
>
>---
>
>So, my recommendation: acknowledge your team leader's
>concerns, but then show her that they are not major.
>
>Don't just tell her that she is wrong.
>In a theoretical sense, she is right.
>Just with very, very, low probability.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
>
Received on Sat Apr 3 01:45:10 2004