On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote: > On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford > <[1]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.
What are you supposed to do when you try to push (or pull) and it get blocked because of a fork ? If there's a fork, it's too late. Fork's happens because autosync is off or because some commits was done while the remote repo was not accessible. When it's not the case, if you try to commit while you are not in sync with the remote repo, you get a warning that it might create a FORK and fossil give you chance to do a *up* before. Then you can figure out if there's some conflict, fix them if necessary, have a discussion with the other developer if necessary and commit again. > > 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. Sometimes, Fork are inevitable. User should understand the concept of a distributed SCM. Fossil have a nice timeline graph that will show you the FORK clearly. And the CLI timeline command tell you that there's a FORK. (by adding *FORK* to the checkin entry): http://www.fossil-scm.org/index.html/info/62b10da0e1fe8ee5fa8b1af9aa35696079bb48ee?txt=1&ln=1825+1829 May be it could help if "fossil status" or "fossil change" command could print a warning when the current checkin is part of a fork ? Regards, -- Martin G. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
