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.

Answer 2

On an open-source project like a game, it makes sense to keep images under revision control, and those are nice to be able to lock (Subversion supports this). For source files, it's better to get into the edit-merge work flow. It's not hard and increases productivity in my experience.

Answer 3

Interesting question. To me, the issue is not so much whether to lock, but how long to lock. In this shop, I'm a minority of one, because I like to merge. I like to know what other people have done to to the code. So what I do is:

• Always work in a local copy of the source tree.

• Run Windiff often against the "official" code and if necessary merge changes down to my local copy. For merging, I use an old Emacs (Epsilon) and have the compare-buffers command bound to a hot-key. Another key says "make the rest of this line like the one in the other file", because many changes are small.

• When I'm ready to check in changes, Windiff tells me what files I need to lock, check in, and unlock. So I keep them locked as short a time as possible, like minutes.

So when Fearless Leader says "Have you checked in your code?" the answer is "I don't have any checked out."

But as I said, I'm a minority of one.

Answer 4

In my opinion, the main reason people use exclusive locking is its simplicity and for them, lack of risk.

If I have exclusive access to a file, I won't have to try and understand someone elses changes to the same file. I don't have to risk making my changes and then having to merge with someone elses when I check in.

If I have an exclusive lock on the files I'm changing, then I know that when I checkin, I will be able to checkin a coherent changeset; it is simpler for me to do this.

The other aspect of merging (esp. automatic merging) is the potential for regression problems. Without good automated tests, every time you do a automatic merge, you may get problems. At least if you have an exclusive lock on something you ensure that someone is looking at the code before it's checked in. This, for some, reduces risk.

What exclusive locking takes away is the potential parallelism of changes. You can't have two people working on a file.

The open source model (lots of people around the world collaborating on different stuff) has promoted the view that locking is bad, but it really does work for some teams. It does avoid real problems. I'm not saying that these problems can't be overcome, but it requires a change in behaviour for people; if you want to change to a non-locking model, you have to persuade them to change to a way of working which can seem harder for them, and can actually (in their view) increase risk cause regressions.

Personally, I prefer not to use locks, but I can see why some people don't like it.

Answer 5

Here's my $0.02.

Locking is an old school of thought for textual Code. Once programmers use merging a couple of times they learn and usually like the power of it.

Valid cases for locks still exist.

• Graphics alterations. 99% of the time you cannot merge 2 peoples work on the same graphic.
• Binary updates.
• Sometimes code can be complex/simple enough to justify only 1 person working on it at a time. In this case it's a project management choice to use a feature.

Answer 6

Addressing your edit comments.

Even RCS and SCCS (the grandfather VCS for most of what runs on Unix/Linux these days) permit concurrent editing access to files, and I'm not referring to separate branches. With SCCS, you could do 'get -k SCCS/s.filename.c' and obtain an editable copy of the file -- and you could use an option ('-p' IIRC) to get it to standard output. You could have other people doing the same. Then, when it came time to check-in, you'd have to ensure that you started with the correct version or do a merge to deal with changes since your starting version was collected, etc. And none of this checking was automated, and conflicts were not handled or marked automatically, and so on. I didn't claim it was easy; just that it could be done. (Under this scheme, the locks would only be held for a short time, while a checkin/merge was in progress. You do have locks still - SCCS requires them, and RCS can be compiled with strict locking required - but only for short-ish durations. But it is hard work - no-one did it because it is such hard work.)

Modern VCS handle most of the issues automatically, or almost automatically. That is their great strength compared to the ancestral systems. And because merging is easy and almost automatic, it allows different styles of development.

I still like locking. The main work system I use is (IBM Rational) Atria ClearCase; for my own development, I use RCS (having given up SCCS around Y2K). Both use locking. But ClearCase has good tools for doing merging, and we do a fair amount of that, not least because there are at least 4 codelines active on the product I work on (4 main versions, that is). And bug fixes in one version quite often apply to the other versions, almost verbatim.

So, locking-only VCS typically do not have good enough merge facilities to encourage the use of concurrent editing of files. More modern VCS have better merging (and also branching) facilities, and therefore do not have as strong a need for locking for more than the shortest term (enough to make the operations on the file - or files in the more advanced systems - atomic).