On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford <amb-fos...@bradfords.org> wrote:
> Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200: > > > If they can happen when two people push to central repository one > > after another, then IMHO they should be blocked. Or at least there > > should be a possibility to enable/disable some kind of lock mechanism. > > I wonder just what this means? What part of the sync should be blocked? > > If I'm not mistaken, Fossil's design prefers to have the fork than not. > > > I agree that good communication is essential, yet I also think the > > best way is to make software actively protecting us from making forks > > by accident. > > The software already warns users that a fork is imminent. They have the > choice to ignore the warning, or not. > If only this were true then this discussion would have been over long ago. Today I got to hear from a team that had a very near serious QA escape due to an undetected fork. In my opinion Fossil needs to either block a push that would result in a fork or on any and every operation loudly complain about any forks lingering in the timeline. Forks add little value but have a potentially high cost because they can be so confusing when they happen. To reiterate; An adequate solution would be on every checkout or update loudly inform the user that there is a fork in the timeline. A much better solution is to block a push that creates a fork and inform the user that they need to fix the fork and push again. > > Andy > -- > TAI64 timestamp: 4000000055248f46 > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
