Source Control - Lock vs. Merge? [closed]

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

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.