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 appear to be built for edit and merge workflows, and many don't even support exclusive locks at all.

However, everyone I work with is of the opinion that exclusive locks are a "must have" for any source control system, and working any other way would be a nightmare. Even recent hires from other companies seem to come in with this idea.

My question isn't who is right. I'm pretty sure what answer I'd get to that. My question is, is there really still any debate over this matter? Is there an honest "pro locking" camp out there that makes a serious case? Is any work being done to advance the art of revision control based around the locking model? Or are locking fans flogging a dead horse?

EDIT: The answers so far have done a good job of explaining why exclusive locks are a good feature to use occasionally. However, I'm talking about promoting a workflow where exclusive locks are used for everything.

Wampumpeag

Well, they are perfectly fine if you absolutely need to ensure that a project is not going to deliver. But then you should also split the project over at least two different organisations that are not co-located, and preferably outsource part of the project. – Shelashelagh

This is a rhetorically toned question and very subjective. In companies where communication is not as good as it should be, exclusive locking let's people actually get work done. You should tag this as subjective, there is no correct answer. – Py

@Ash: (+1) It may be subjective, but it is important. In fact, I've found exclusive locking do the opposite. It prevents work from getting done, because people lock things casually and forget to unlock them, and then go on vacation. Of course they shouldn't do that, but even so, they do. – Involucre

@MikeDunlavey, forgetting locked files isn't a problem of the locking system, it's a problem of people who misuse it. People should be fixed, not the system. It's the same as saying that the door to your house doesn't work if you're locked outside the house because you forgot the key: that's not a key/door system flaw, it's your own. – Amarette

Answer 1

If you're used to exclusive locking, then it's hard to embrace the edit-merge workflow.

Exclusive locking has its benefits, especially for binary files (images, videos, ...) which can't be merged automatically or not at all.

But: the need for exclusive locking always indicates another problem: good communication between people working on the project. Exclusive locking provides a poor replacement: it tells users that someone else is already working on that particular file - something they should know without using a version control system.

Since there are better ways to help with the communication among team members, most (all?) version control systems don't implement exclusive locking anymore or just a reduced version (i.e., locking, but such that those locks are not enforced).

It's not the job of a version control system to help with the communication.

Evolutionist

You could also mention that the modern distributed version controls don't even have any way to get a lock since there is no real-time communication between the repositories. – Kaylakayle

Certainly not ALL version control systems don't provide exclusive locking - Sourcegear Vault for one does. In fact it's turned on by default. – Bezique

Answer 2

I like having the option to exclusive-lock some file[s].

Having an exclusive lock is necessary, e.g. for binary files.

It's also semi-necessary for some machine-generated non-binary files (e.g. for Visual Studio project files, which don't 'merge' at all well if ever there are two parallel changes to be merged).

Mosby

Both of those cases (binary files and VS files) help illustrate why they don't belong in source control. Source control is for source: text files that contribute to producing an automated solution. VS files are not source, they are developer-specific tool configuration. – Anastomosis

VS Project don't merge well not because they're VS project files, but because they're XML. Most merge files do a very bad job dealing with XML in general. That doesn't mean they shouldn't be versioned. They absolutely should. Hopefully you can find a VCS that lets you switch merge tools. – Toxophilite

@Rob I'm thinking of VS files like the *.csproj files (for C#) or *.vcproj (for C++) or *.sln: these aren't exactly source files, but they are [like] makefiles, not developer-specific, must be version-controlled, shared and edited by all developers, and the software can't be built without them. – Mosby

I've never had any problems with merging csproj or sln files... I always merge those by using the merge tool though, just to be sure that it does what I think it will. And usually it does :) – Victorie

@Victorie I think that it (i.e. the complexity of the project file and the extent to which Visual Studio changes it) depends on the type of project: I'd had problems with C++ project files. – Mosby

-1 There is no reason at all binary files could not be merged. XML is easy to merge. Merging derived files is even easier, that's a NOOP – Shelashelagh

"XML is easy to merge" -- not necessarily: an XML-format project file includes attributes and text, e.g. GUIDs ... and Visual Studio might arbitrarily re-sequence XML elements, and assign them new GUIDs ... which causes merge errors (because everything has changed), which means that you have to merge by hand/eye ... but because everything has changed, it's too difficult/complicated to merge by hand/eye ... and so given that a merge is impossible, its better to prevent duplicate checkouts in the first place. – Mosby

If it hands out new GUIDs, it has changed. Some tools might not understand the concept of identity... I never merge by hand, I use the right tools for it. You can work around stupid tools that do not understand identity. – Shelashelagh

Yes it has changed. If was was only a small/local change in the project file (corresponding to a small/local change I made to the project), then two such small/local changes by different programmers would be distinct and easy to merge. However because a small change by a program results in changes throughout the file, this causes merge conflicts if there are two such changes: so for this kind of file (same as for binary files), I prefer exclusive checkout. – Mosby

Bad tools. equivalence is easy to prove – Shelashelagh

@Stephan If you're trying to helpful, I'm not sure what specific advice you're trying to offer: which tools are bad, and which are better? – Mosby

If you import your VSS history into subversion you often see that project files are marked as binary because VSS doesn't understand that the UTF-8 byte order mark specifies a text file. And as binary files need manual merging, ... – Taiwan

Answer 3

If you believe that merges are hard (and while we've come a long way, they can be in some circumstances), and you don't have programmers frequently wanting to edit the same file, exclusive locking isn't necessarily that bad.

I wouldn't use them on an open source project, obviously, but in the corporate world where the rules are stricter and you can walk over to a guy and say "can I break your lock?", it gives visibility into what people are working on and avoids conflicts so they don't have to be resolved later.

If two people really need to work on a file at the same time, often you can branch that file, and so long as the tool makes it clear that that branch needs to be merged back in, you can do that and resolve any conflicts then.

That said, I don't think I want to have to work in an exclusive locking world again.

Toxophilite

Hmmm. I'm thinking your insight about it being a far worse model in an OpenSource project might be a very salient point here. That would also explain why folks on the 'net seem to hate that method so much more. – Wampumpeag

"Lock" on open source project file = denial of service attack. Of course, it results in denial of service in many corporate projects, as well. – Opportuna

Keep in mind this answer was written in 2009, before git was really a thing and merges aren't nearly as much of a pain as they used to be, if your corporate overlords let you use the proper tools. – Toxophilite

Answer 4

Exclusive locking is the best you can do in a worst-case scenario, so its presence always tells me that there are bigger problems.

One of those bigger problems is bad organization of code. On one of my consulting gigs for a major telecomm, eight out of thirty team members were constantly working on the same source file (a VB.NET "god" form). We would wait for someone else to finish their work and release the exclusive lock (VSS), then the next person in the pecking order would immediately lock the file to apply their changes. This took forever because they had to reintegrate all their work into the new code that they could see only just then. Since I was the new guy, I was on the bottom of the pecking order and I NEVER was allowed to check in my code changes. I eventually went to the project manager/director and suggested that I be tasked with another part of the application functionality. This project eventually self-destructed, but most of us left as we realized that inevitability. Note that the use of VSS integration was a crucial part of this failure, too, since it forces early acquisitions of that precious file lock.

So, a well-organized project should almost never result in two people working on the same part of the same source file at the same time. Therefore, no need for exclusive locking.

Another of those bigger problems is putting binary files into source control. Source control tools are not designed to handle binaries, and that is a good thing. Binaries require different treatment, and source control tools cannot support that special treatment. Binaries must be managed as a whole, not as parts (lines). Binaries tend to be far more stable/unchanging. Binaries tend to need explicit versioning different from source control versioning, often with multiple versions available simultaneously. Binaries are often generated from source, so only the source needs to be controlled (and the generation scripts). See Maven repositories for a binary-friendly storage design (but please don't use Maven itself, use Apache Ivy).

Anastomosis

Answer 5

The arguments for locking are really bad. They basically say: our tools are so bad they cannot merge, so we lock.

Shelashelagh

Actually, around here they insist merging itself is a nightmare that must be avoided. Not quite the same thing, at least in their minds. – Wampumpeag

Well, they are wrong. Merging is easy. As long as you do it often and use "the right tools". If merging is painful, the work is not split up correctly. That is the problem, not the merging – Shelashelagh

Another argument against locks: Show one case where locks could not be replaced by a combination of a communication style, and a workflow that allows everyone to keep working, at all times. Now count up the lost time "waiting for locks". Locking == Waiting. – Ostrowski

Actually merging is still done either way. With locking the second person to check out a file is forced to do the merge; without locking the second person to check in has to do the merge. Nevertheless a good point. – Mede

Answer 6

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.

Teletype

Once I worked in a group where this kind of thing sometimes happened. It was called "Dueling Deltas". – Involucre

Answer 7

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.

Deedee

The three cases are no valid reasons for an exclusive lock. There is a difference between an indicator that someone else is working on it and a lock. – Shelashelagh

@Stephan: Explain why they are not valid in depth please. Also what revision control package contains this indicator function that you speak of? I have used subversion almost exclusively and to the best of my knowledge there isn't an "indicator" action in it. – Deedee

Answer 8

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.

Weightlessness

Answer 9

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.

Involucre

Interesting way of implementing an edit-merge workflow in a locked-checkout environment with third-party tool. I once tried doing that using Git. It became a real pain though. Still, I think there's always that one file (can you say "makefile" or ".sln" file?) that everyone ends up having to manually edit and merge outside of the locking system, isn't there? – Wampumpeag

@T.E.D.: I'm not familiar with Git. I've done this with Perforce, VisualSourceSafe, all the way back to SCCS in the 80s. The makefiles tend to have relative paths so don't need adjusting. Now I use DOS drive letters E: and F: to refer to the parallel source trees, and I have bat files to do "cd" simultaneously in both, so I don't have to worry about long path names. When there are multiple code branches to manage, it's more complicated, but that's the case regardless. Anyway, I'm glad to see this issue being discussed. – Involucre

Answer 10

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.

Greenburg

Answer 11

A bit late to this discussion but to anybody who has read and digested Steve Maguire's Writing Solid Code a central point is to have your tools detect and identify as many problems as possible.

A compiler doesn't get tired after 12 or more straight hours and forget to issue a syntax error. But it is quite easy to forget a manual step of initiating a communication and paying for it later.

If you need to version control a binary file then you need some form of locking to prevent - or at least warn of - an accidental overwrite. It must be a fundamental feature of any VCS even a distributed one. To use such a feature in a DVCS may require the creation of a central repository but is that so evil? If you use a DVCS in any sort of corporate environment, you will have a central repo to ensure business continuity.

Lanyard

"If you need to version control a binary file": nope, not in a DVCS you don't always have to (https://mcmap.net/q/48087/-how-to-handle-a-large-git-repository). "you need some form of locking" that does not exist in a DVCS workd (where developers are all over the world in their own separate environment): https://mcmap.net/q/48085/-git-dvcs-lock-or-checked-out-the-file-as-like-svn-and-conflict-merge-the-files/6309 or https://mcmap.net/q/48086/-source-control-lock-vs-merge-closed/6309 – Fifteen

Actually, I really appreciate folks piping in here after three years with an updated point of view. There hasn't been much change here at work in the attitude toward locks, and I think this question is just as valid today as it was then. – Wampumpeag

Developrs are not always all over the world but can be (and are) in the offices right next to me. DVCS does offer us many advantages and I wish we had it when the server farm had a major hiccup. But we do a LOT of software development work in LabView which is 100% binary. There we are stuck using a traditional locking VCS. This is production software which must be versioned and traceable. – Lanyard

@Lanyard “Versioned and traceable” has nothing to do with locking or lack thereof. I do versioned and traceable development with non-locking VCSs. So do lots of people. – Gravitation

Answer 12

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).

Arel

I didn't understand WHY you like locking. I hate locking. I think I can go on at length about why. But I want to know why some people (even only three on the planet) say they like it? I must know! When, for instance, can locking be anything other than an impediment? – Ostrowski