As most of you probably know, the new netsync code sometimes produces
odd revision in/out counts. I patched netsync.cc to print the id of
revisions sent/received, and got the following:
monotone: Sent revision 'c474ab284916f70c4bc815fbe48bef896a49e9e9'
monotone: Sent revision '33e04bf7daf908f6259f6b4caf8440a4f5c9d525'
monotone: Received revision '693637658121e44bd05a61708b43ebbe250bb511'
monotone: Received revision 'c474f6eed5f07b004390d428b70280aab5c98379'
monotone: Received revision '3310608b55ca55db1fc8beb3454b2f0c2a14ef79'
monotone: Received revision 'e0bdd49c40f80f5a831c3e0ec3f974b1a2086054'
monotone: Received revision 'c7d71aa63a5fc920dc8733efae966be974ef41b7'
monotone: Received revision '6ee365b0f2e23562ab1c9639ae8155a8c8f1a521'
monotone: Received revision 'fdcb499564d28eae69c5787fba2bd10993a33df5'
What's most odd is that the two sent revisions both have children, which
were not sent and which do not match any of the received revisions.
They're also revisions I received through an earlier sync, so the server
should have them already.
The received revisions appear to be all in good order, as they all
either are leaves, or have only children that were received after them.
--- netsync.cc 81c12af4a0791840ac675220fd06bee263434554
+++ netsync.cc ffa9c7adc1d8316198c3ae37befaded5fe2be3b3
@@ -827,6 +827,7 @@
decrement_if_nonzero(ty, rev_refiner.items_to_receive);
if (revision_in_ticker.get() != NULL)
++(*revision_in_ticker);
+ P(F("Received revision '%s'") % encode_hexenc(ident()));
break;
case key_item:
decrement_if_nonzero(ty, key_refiner.items_to_receive);
@@ -856,6 +857,7 @@
rev_refiner.items_to_send.erase(ident);
if (revision_out_ticker.get() != NULL)
++(*revision_out_ticker);
+ P(F("Sent revision '%s'") % encode_hexenc(ident()));
break;
case key_item:
key_refiner.items_to_send.erase(ident);
_______________________________________________
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
