Source Control - Lock vs. Merge? [closed]

Answer 1

I think that it depends on the case. Would you take a plane if you know that the files that control the plane were changed simultanously by many people and then merged?

In silly applications merge approach can be used, but if we are talking about serious systems.... like bank systems, etc...

Answer 2

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 3

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.

Answer 4

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 5

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 6

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.