3 ms·

No VCS will be merge conflict-less without locking files. I'd rather not lock files.

• deleted 7y ago
  [deleted]
• ben509 7y ago
  I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.
  • 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 ago
      I'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.