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