4 ms·
This reminds me, I eventually learned that there were two styles of cooperating with others in a lock-based system, each with different advantages and disadvant
by adrianmonk 3y ago
This reminds me, I eventually learned that there were two styles of cooperating with others in a lock-based system, each with different advantages and disadvantages:
(1) Lock the file(s) as soon as you start coding. Commit when finished coding.
(2) Do all your coding against unlocked files. When finished coding, then lock the files, and copy over your edits to them. Then commit.
Style 1 is fine if there is low contention for the files, like a team with few members or a part of the codebase that is rarely changed. You never have to manually copy your edits to an updated file. If everyone uses this style, there's no such thing as a conflict. It's not even possible.
You also don't necessarily have to coordinate offline with anyone to prevent situations where people unknowingly proceeding in incompatible directions with the same file. Coordination is still better, but locks naturally prevent this to some extent.
You do need to be responsive to emails to avoid blocking others. And it's possible to forget you have something locked when you don't even need it to be, like if you were just starting to code and paused or abandoned that work.
You may have disagreements about whose work is more important and whether you should release a lock or make the other person wait.
Style 2 is helpful if there is high contention. You need to plan and coordinate more since otherwise it's possible two people could make incompatible changes to the same file without knowing it until the last moment.
If the base version of a file changed (since you started coding against it), you have to manually copy over your changes. This definitely involves tedium and may require resolving conflicts.
This style is a lot like what we're accustomed to today with Git (and Subversion and CVS before that). But updates and merging are totally manual instead of mostly automated. Back in ancient times, codebases were smaller, so although that was definitely a burden, it was doable.