Source Control - Lock vs. Merge?

Question

A lot of programmers who are used Visual Studio have a hard time adjusting to the fact that in other source control systems, files do not need to be locked/checked out to one developer at any given time.

Proponents of merging say that allowing two people to work on the same file speeds up productivity since it eliminates queuing up for the same source file. It also avoids cases where code needs to be written but the source is checked out to a guy who just left on a two-week vacation.

Locking advocates say that a lot of risk is introduced when more than one person works on the same file simultaneously. Communication and coordination between team members becomes much more necessary when using the merge model, according to them. Plus, a lot of people seem to mistrust automated merges.

What is the most compelling reason for you to use one method over the other?

Answer 1

Locking files may not scale very well to larger team. With version control systems that utilizes a lot of branching and merging, it simply may not be practical to let any one person give such control over the repository (thus, not scale to larger team).

With Subversion, for example, branching is a pointer copy, so you can easily create a TRY branch to avoid corrupting the trunk if you are experimenting with something, but want to commit.

With distributed version control systems like Git, every check out essentially is a branch.

Answer 2

Having switched from locked model to merge model, I will make the following observations:

• Most merge users tend to stay fairly close to the "head" version of the branch they're developing on. This normally means that the dramatic merge problems are not very common.
• In 10 or so years of merge model usage, I have only experienced a couple of really bad merge issues. In both cases this was because 2 people had solved the same problem.
• We normally resolve merge issues without communicating with the other party ;)
• "Lock" model VC is ok if a system is in a stable maintenance phase with little changes.
• Lock model VC is ok if your team is small (I'd say 1-2 people ;)

IMHO merge model is vastly superior because it allows me freedom while working with code. It may not be the best model for "going dark" with the code for 1 week, but then again with "lock" model this is an equally big problem. No-one shold go dark with code for a week.

Answer 3

Merges are good. Programmers working on the same file, should be communicating anyway. If they are NOT communicating, there are graver problems in that code.

Merge is the natural way of doing things, it brings discipline, saves time( imagine both the programmers ending up refactoring the same code ).

Lock is reactive...merge is proactive...

Answer 4

I think the merge model is far superior, it's more flexible, users can work in parallel, never waiting for one another, and the amount of time that takes to resolve conflicts is far less than the time lost by a locking model. Most of the time, changes made to a file don't conflict and can be automatically merged.

That's probably why it's the default model in most modern source control systems.

But in the end, the critical factor is always user communication. When users communicate poorly, conflicts for sure will increase.

Answer 5

Common complaint against locking VCSes is that you have a problem when somebody goes for a vacation or conference leaving some files locked :)

Answer 6

Merge is the right approach, but to add to the previous answer, it should respect a few criteria to be efficient.

• the branch is well defined (it does not represent a "too broad" development effort, in which developers would have to modify all files, multiplying the chances to multiple concurrent modification of one common file with potential conflict)
• the notification (that the file is already being changed) is clearly made when one developer starts to modify a file already reserved by another colleague.
• common configuration files (where every developer need to follow a set of pre-defined values, except for one custom local path needing to be re-defined for each programmer) are not "reserved" by anyone, but simply modified in their private workspace.

Also, keep in mind there is also the possibility to have a combination of both:

• "lock": the first developer to modify a file will be the first to commit it. Every other developers can also modify the same file, but will have to wait for the first one to commit before starting to merge their own modifications.
• "merge": when a developer commit a file already changed by a colleague, he merges his changes.

In that case, you should make sure a "release" mechanism exist to avoid being blocked by the first developer.

Answer 7

Locking advocates are wrong, if there is such a thing as one who advocates for that. Every team I've met using the old-fashioned locking style system has complained about it, and looked longingly at the people using other methods. I worked on a project for one place that were forced to use a locking system and opted to use NO CONTROL at all (so I set up a secret SVN branch, even though I much prefer Bzr or Git).

So, I suspect that the only "locking advocates" are employees of a locking system's marketing department.

Answer 8

I was very scared of the idea of merges myself, having memories of nighmares trying to merge code back in the 80's. However, I downloaded Subversion and Git and played with them a bit, and am impressed with their promise. Its a shame I'm the only one here who is.

One thing I've done that you can try: Keep track yourself. Since the locking model is more pessimistic, this is easy to do if you are working under that model. Every time you have a lock conflict with another developer, go over and talk to them. Keep track of the following:

1. How many times they didn't mean to check it out/forgot about it/didn't know it was checked out.
2. How many times they aren't available (on vacation, out sick, etc).
3. How many times they legitimately have it checked out, but are modifying totally unrelated parts of the file to what you wanted to modify.
4. How many times they modified a part of the file that would conflict with the changes you wanted to make.

4 is the only situation where it can be argued that locking helped you, and covers every such occurrance. What I've found over the last 3 years I've been doing this is that nearly every problem is of the 1-3 variety. I think I found a 4 once. But if I add up all the time lost to 1-3, it's tremendous.

Answer 9

The merge model is kind of like swimming. People who haven't done it at first are afraid of it, but everybody who knows how to do it loves it. Some people have bad experiences early on, and most people just have to experience it and get over that initial fear.

Answer 10

The biggest merge problems I ever had were at a site where we had locking version control (SCCS, to be precise - this was a while ago).

What would happen is that person A would be working on something, and would have the file checked out. Person B would get an urgent request to fix something for a customer, and would have to change that file.

This played out in several ways. Sometimes, A would check in, B would make a change, and A would then continue from A's working copy and wipe out B's change. Sometimes, B would get started on a copied-out copy, since time was of the essence and changes could take a while to get right, and overwrite A's changes. Sometimes B's changes would interact with A's changes, and some of A's changes would be mangled or lost. There was no warning in the latter case.

In a merging VCS, A and B make their changes, and the system makes sure nothing is lost. In the last case, the VCS notes the conflict, so it won't be missed.

There was also a problem with doing a larger change to a program file, as it could be interrupted by necessary fixes, making it much harder to finish.

I've never seen a production environment where it was possible to guarantee that two people wouldn't have to work on the same file at about the same time. Merging VCSs handle that situation well. Locking VCSs don't.

Answer 11

I THINK EXCLUSIVE LOCK ROCKS!

Answer 12

Merging is always problematic and counterproductive and should be avoided at all costs. Merging large code changes and refactored files is a pain. Forcing an Optimistic locking model on all developers is wrong.