RE: Need ammo against those who say "lock everything"

> 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