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

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

Answer 2

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.

Answer 3

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.

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

Answer 5

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

Answer 6

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.