On Thursday, December 03, 2015 9:48 AM, Andy Bradford wrote:
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.
"round-trips" being during the push (i.e. post commit). Sorry I was using
the terminology of what was being shown on screen -- not combining the pre
and post commit numbers.
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).
So... doing fossil rebuild then test-clusters on the server results in
"all artifacts reachable through clusters".
Hooray! However... doing then a sync on my clone, then doing the
fossil test-clusters again on the server results in:
170931 unreachable artifacts:
127299 000017df491816cdbd40fcbca031950decdf9532
150554 000067ad9657662b33a669d87934b6df91a62f71
134125 000091fa0dc5528c0595b16c4cc56f9365bfbba0
68008 0000cc81620bd3ff86379b744e4dae91df8f6175
[...]
However, on my clone I get:
$ fossil test-clusters
all artifacts reachable through clusters
Both server and client are running 1.34.
Cheers
Andy
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
