Thus said Andy Gibbs on Thu, 03 Dec 2015 08:56:42 +0100: > For reference, a single commit may lead to around 100 "round-trips" to > then sync with the server (assuming no commits coming back as well).
If you are using autosync (the default) then Fossill will first pull, before it pushes. Are these the ``round-trips'' you mean? If so, what is more important to know is how many round-trips are made during the ``push'' synchronization part of the autosync. Though, again, the max-download may have just been a red-herring, and just another clue in the puzzle that helped discover the actual problem. > Ok, this produced a very long list starting thusly: > > 170716 unreachable artifacts: > > Should I be worried?! Not yet... Please run: fossil rebuild fossil test-clusters Then we'll get the true picture of whether or not you have something to be worried about. The clusters are only used for sync operations, not clone, so if one goes missing, then it makes it so clients cannot pull new content (the original bug that was fixed). > I am sorry this is awfully vague - it honestly doesn't happen enough > I that have a clear memory of all the details! I hope it helps though. That's alright. The most important thing to know is whether or not Fossil was 1.30 or newer when this happened. :-) Thanks, Andy -- TAI64 timestamp: 4000000056600204 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
