What are some arguments against locking?
David Frey
dpfrey at shaw.ca
Wed Jun 25 16:10:08 CDT 2008
Locking works differently on different systems:
- Locks may be mandatory or optional.
- Locks may be user breakable or admin breakable.
Mandatory locking really sucks if there is any overlap between the files
that developers work on. Imagine that you are fixing a bug and that bug
fix requires changes to 6 files. In a mandatory locking system, you
start checking out the first 4 files and then realize that the last two
are locked. You now have two options:
1) Wait for the 2 locked files to be checked in so that you can lock them
2) Modify those files without a lock. This will probably involve
manually merging your changes into updated versions of the 2 files once
the lock is released. This may also involve remembering which files you
have modified locally without checking out.
There is also a good chance that someone else is waiting for those 4
files you checked out while you are waiting for the other 2 files to be
checked-in.
Can you tell that I am forced to use an archaic, mandatory locking RCS?
Good luck trying to sell Mercurial to your employer. I have given up.
:(
Dave
On 6/25/2008, "Paul Chiusano" <paul.chiusano at gmail.com> 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
More information about the Mercurial
mailing list