Thus said Ron Aaron on Fri, 13 Jun 2014 07:43:25 +0300: > So I could have the situation where C1 pushes and is also pulling > (though locks should prevent any problems), and later on C2 pulls. I > don't have the super-long-time push, but it does seem to occur more > often when the push involves a large number (or number of bytes) of > files.
While I was working on making autosync make more passes, I hammered a test repository like this: M1: jot 100 | while read x; do dd if=/dev/urandom bs=1k count=100 | hexdump > file.$x; done fossil ci -m test M2: echo $RANDOM > file fossil ci (or sometimes fossil update). Either way, this made for massive transfers and I never ran into this issue. The laptop representing M2 was on a slower wifi link (not LAN) and it would often take about 60 seconds to transfer. I even sometimes through in an additional commit on M1 while M2 was still transfering and I still found all expected content on M2 after all was said and done. I can continue to try this route to see if there might be something. By the way, what version of Fossil are you running on your clients (and server)? Thanks, Andy -- TAI64 timestamp: 40000000539a88f7 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
