23 ms·
The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking t
by wyoung2 7y ago
The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS.
I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences.
We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab https://www.fossil-scm.org/forum/forumpost/2afc32b1ab
We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.
- ben509 7y agoI'm talking about purely advisory locks. Accessing a locked file would let you know who locked it, and if you unlock it, it would just notify them. So it's just a communications mechanism in addition to regular merges. The alternate method is that locking a file marks you as an interested party to a merge, allowing you to review the correctness of a merge. This would be purely to avoid changes being lost during merges.