Question

We multiple programmers have to work at one project simultaneously. Sometimes we have to work in a single file.

Which one is better

• File locking
• Branching

Or, how to use both of them in better ways?

Answer 1

Non-locking checkout (what you call “Branching”) is always better. Locking checkout leads to no check-in conflicts, at the expense of check-out conflicts. Checkout conflicts can be mitigated provided that people are 100% reliable (and fast). Otherwise, you have people sitting on their hands to get a check-out, instead of working in parallel.

For example, I start working on a file, so I lock it. Then I go to lunch. Nobody else gets to work with this file while I am gone. I come back from lunch, my email box is full of “hey please unlock XXX”, my phone has messages, etc. These “pressures” eventually lead to people doing their work outside of revision control, and then “merging” them into the revision control system (which is prone to missed item failure).

With non-locking checkout, You and I both checkout, without coordination, and we both (again uncoordinated) modify a few of the same files. I check in first, which will merge with the repository smoothly (again I didn’t coordinate with you). You try to check in, but three of your files were based on copies made “prior” to the “current” copy of the file. You are now tasked with a choice. Delete your file and make the changes according to the “current” copy, or download the changes applied to make the “current” copy from the “old” copy and merge those changes into your submission. You only wait on yourself.

With non-locking checkout, one person doesn’t impact the rest of the team for whatever item they are attempting to do. They might incur more work for themselves if they chose to not merge often or merge early; but, they do not incur more work for others.