What are some arguments against locking?

[Roman Kennke]

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.

Where I work, we only use locking for automated processes, so that they
don't get in the way with developer work. We never use locking for
developers and I can imagine that it would be painful. What happens when
somebody forgets to unlock a file and goes home or in holiday? Locking
is even more complicated (impossible?) in a distributed system. Every
developer is working on its own repository, how would he lock a remote
one? And why? The merging argument is also moot in my experience. This
probably stems from older systems where merging has been a pain (like
CVS). In Mercurial it is much better, and actually, merging becomes a
day-to-day work, just like committing. Not that Mercurial does something
special here, but it utilizes a couple of external tools for automatic
and interactive merging. Give it a try. Be prepared that the learning
curve for old-school RCS users is steep. (I know this, we have these
kind of conservative my-old-RCS-works-this-way-make-HG-work-the-same
kind of people in my team).

Cheers, Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt