What are some arguments against locking?
Bill Barry
after.fallout at gmail.com
Wed Jun 25 15:13:23 CDT 2008
It sounds like your coworker hasn't had much experience with merging
changes and is fearing the unknown. On a busy day for me (where multiple
devs are working on the same project and everyone makes 40+ commits in
the day) about 25% of the commits are merges (with 4 developers, that
means over 40 merges in one day). Yesterday was one such day, roughly
half of those merges were dealing with the same files. Only one brought
up the merge tool, because two of us made the same change (with spacing
differences) to a file. I've never seen a merge that took more than a
couple minutes to deal with (well, except one time when a coworker was
using VSS *with locking* and tried to merge from the explorer view only
to find out that VSS had damaged history).
The reality is, such a massive merge isn't just relatively infrequent,
it is vanishingly rare. The only cases where I would have expected it to
happen (in our application, we refactored the data access layer during a
major release and then had to issue a point release to the previous
version with dozens of fixes to the same files due to a memory leak), it
still merged automatically (we were using svn at the time) and in that
case (and several like it for different reasons), locking wouldn't have
helped at all. I'd say the use case for locking is rare enough that I
wouldn't consider a tool that only had that as a way to stop merges
(instead of good merge algorithms). Merges will happen in any scm, hg
simply embraces them.
To try to put it better, I'll never use locking in a repository for
several reasons:
a. Locking requires someone to be available to remove locks (perhaps an
administrator) when the locker forgets to unlock before going somewhere.
b. Locking slows people down. For instance if I had to modify a function
at the top of a file and you needed to modify something at the bottom,
one of us needs to wait.
c. Locking does not solve the merge problem. If you have two versions in
a support phase at one time you will still need to deal with
transplanting changes from one to another at some point.
Another perspective is here:
http://svnbook.red-bean.com/en/1.4/svn.basic.vsn-models.html
Paul Chiusano wrote:
> Hi,
>
> I am currently evaluating Mercurial for use at my company, where we
> currently use StarTeam (gak!). One of my coworkers seems to think that
> locking is a very useful feature and that it is a nonstarter to even
> consider a VCS without it. Although I disagree strongly with this, I
> haven't been too successful in convincing him, so I thought I would
> ask people here for some additional arguments for why locking is not
> usually useful.
>
> For context, my coworker's basic argument is that sometimes people
> make changes to the same file and the changes are difficult to merge,
> requiring hours of work to figure out what the merged changes should
> look like. Even if this is relatively infrequent, it's enough of a
> time sink to make it worth preventing it entirely by locking. How do
> other people avoid situations like this when using Mercurial? Note
> that I am NOT saying I agree with this argument at all, I just wanted
> to have some additional perspectives on this so that I can explain
> things a bit better.
>
> Paul
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080625/9db10366/attachment.htm
More information about the Mercurial
mailing list