Revision control locking: Is the jury still out?

Question

When I\'m online it seems that everyone has agreed that using the exclusive locking workflow in source control is a Bad Thing. All the new revision control systems I see app

Answer 1

In my experience, it's often necessary for two people to work on the same file at the same time. (There are, presumably, shops where this doesn't happen, but I have fairly varied experience to draw on.)

In these cases, it is necessary for both people to get copies of the original, do their work, and merge their changes. In non-locking VCSs, this is done automatically and accurately for the most part.

With a locking VCS, what happens is that one person gets the lock. If that person finishes first, great; if not, the other person gets to wait before being able to introduce changes. Sometimes it is necessary to make a quick bug fix while somebody is in the middle of a long change process, for example. Once the second person has the lock, the second person needs to merge the changes, typically manually, and check in the new version. On several occasions, I've seen the first person changes dropped entirely, as the second person didn't bother with the manual merge. Frequently this merge is done hastily, either out of distaste for the job or simple time pressure.

Therefore, if two people need to work on the same file at the same time, a non-locking VCS is almost always better.

If this doesn't come up, and two people never need to work on the same file at the same time, it doesn't matter which you use.