2015-04-13 6:31 GMT+02:00 Andy Bradford <amb-fos...@bradfords.org>:
> 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
>
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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
