On Mon, Apr 13, 2015 at 1:59 AM, Jan Nijtmans <[email protected]> wrote:
> 2015-04-13 6:31 GMT+02:00 Andy Bradford <[email protected]>: > >> It's not yet merged to trunk, but I have borrowed from Jan's work and >> merged into the sync-forkwarn branch for what I think will provide a >> better experience (e.g. almost no false positives). >> >> I say almost none, because it's possible that if your sync is cut-off, >> you may end up with a node that has a fork which has already been >> merged, but for which you didn't receive the correction (what are the >> odds?). >> >> But on the whole, I think this is much more reliable: >> >> https://www.fossil-scm.org/index.html/info/d0e2f1bd3e71ebf6 >> > On a branch with a fork if I do "fossil up <someoldnode>" I do not get a warning about the fork. fossil status => no warning (expected I think from the conversation) fossil up branchname => get warning fossil up <othertip-nodeid> => get warning Pretty nice. I'd have liked fossil status to report forks but as is this covers most scenarios. > > Just two remarks: > - I'm not sure if I want to be reminded when someone else causes a > fork on a branch I'm not working on. But if there is such a desire > with other people, I'm not principally against it. > - The function primary_parent_pid_from_rid() is not used anywhere. > > I went ahead, so the fork detection for fossil update/status/info > (I din't hear anyone against that) will receive some more > wide-spread testing. I'll do more testing on the "sync-forkwarn". > > Any more feedback welcome! > > Regards, > Jan Nijtmans > > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
