Source Control - Lock vs. Merge? [closed]

Answer 1

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 2

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 3

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

Answer 4

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 5

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 6

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.