Thus said Jan Nijtmans on Sun, 19 Apr 2015 21:10:25 +0200: > Explanation: the current code in "sync-forkwarn" doesn't do the > fork-check at the end of the sync, it does it at the end of each > round-trip.
I've altered the change and now it will only check at the end of the complete sync. Also, it only warns if it encounters a fork that has not previously been seen (ignoring any additional checkins on a fork unless they also are new forks). I think this will minimize fork warning fatigue that is an outstanding concern. http://www.fossil-scm.org/index.html/info/64b221aacf136594 By the way, I'm not sure if this is a bug (because we're not really cloning as we normally would), but while testing using your method of creating an empty repository, altering the project-code and pulling the Fossil repository, after the pull is complete, while no warnings are issued, ``fossil forks'' actually reports forks. The difference in time for such a big sync remains negligible, perhaps even improved results from when you tested (I suspect the faster time for the [64b221aacf] below was due to network causes): $ ./fossil version This is fossil version 1.32 [64b221aacf] 2015-04-23 00:35:34 UTC $ ./fossil new z.fossil ... $ printf "UPDATE config SET value = 'CE59BB9F186226D80E49D1FA2DB29F935CCA0333' WHERE name = 'project-code';\nDELETE FROM blob;\nDELETE FROM event;\nDELETE FROM unclustered;\nDELETE FROM tagxref;\nDELETE FROM rcvfrom;\nDELETE FROM leaf;\n" | ./fossil sql -R z.fossil $ time ./fossil pull -R z.fossil http://www3.fossil-scm.org/site.cgi Round-trips: 270 Artifacts sent: 0 received: 30708 Pull done, sent: 851133 received: 19754467 ip: 72.52.64.58 real 3m54.302s user 0m49.110s sys 0m3.743s $ fossil version This is fossil version 1.32 [92be5246f8] 2015-04-20 07:20:05 UTC $ fossil new z.fossil ... $ printf "UPDATE config SET value = 'CE59BB9F186226D80E49D1FA2DB29F935CCA0333' WHERE name = 'project-code';\nDELETE FROM blob;\nDELETE FROM event;\nDELETE FROM unclustered;\nDELETE FROM tagxref;\nDELETE FROM rcvfrom;\nDELETE FROM leaf;\n" | fossil sql -R z.fossil $ time fossil pull -R z.fossil http://www3.fossil-scm.org/site.cgi Round-trips: 270 Artifacts sent: 0 received: 30708 Pull done, sent: 851139 received: 19754477 ip: 72.52.64.58 real 4m2.294s user 0m40.539s sys 0m3.552s I don't think the problem is with ``fossil forks'' however, because after running ``fossil rebuild'' on z.fossil, ``fossil forks'' correctly reports that there are no forks. So it seems that for whatever reason, running ``fossil pull'' the way we are for the test results in not all nodes being properly designated in the tables. This behavior exists in trunk as well. $ ./fossil forks -R z.fossil (1) 2015-02-24 06:40:00 [8c3e6404b0] Let -x imply --emptydirs and --dotfiles (user: jan.nijtmans tags: cleanX-no-clean-glob) (2) 2013-06-21 09:27:19 [dfb47a2a2e] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (3) 2013-06-19 07:14:13 [cbf9660369] rebase (user: jan.nijtmans tags: cleanX-no-clean-glob) (4) 2013-04-03 07:36:05 [6159a7f281] rebase (user: jan.nijtmans tags: clean-with-ignore) (5) 2013-04-02 09:31:26 [bdd9790484] merge trunk (user: jan.nijtmans tags: clean-with-ignore) $ ./fossil rebuild z.fossil 100.0% complete... $ ./fossil forks -R z.fossil $ Andy -- TAI64 timestamp: 4000000055385013 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
