Thus said Richard Hipp on Thu, 17 Apr 2014 11:33:59 -0400: > > Would that be a valid strategy? Couldn't we end up with a > > partial state which we can't work from until the pull finishes to > > completion? > > > The logic (in manifest.c) is designed to be able to deal with partial > state transfers. I'm not saying there are definitely no bugs, but I'm > pretty sure it does work.
I've made some changes on the per-round-trip-commit branch that implement what you suggested, but I believe I've run into a potential bug---though perhaps introduced by my most recent changes. It now successfully COMMITs with each round-trip and if I interrupt the transfer the next time I pull, it only gets those things that were missed in the previous sync. This part works great as far as I can tell! However, with checkin [1317331eed] it now allows errors that happen during the http_exchange to actually be returned to the caller, so a network failue will also result in a COMMIT (rather than a fatal error). It seems that this latter behavior introduces (or uncovers) a serious problem. While the sync operation was running, if the network connection is killed at just the right moment, the sync operation does indeed fail, but then the last set of changes gets committed and the update continues as follows: $ fossil up Autosync: http://amb@remote:8080/ Round-trips: 11 Artifacts sent: 0 received: 101 server did not reply Pull finished with 16512 bytes sent, 16267948 bytes received Autosync failed content missing for file.77 UPDATE file.1 ... REMOVE file.77 ... updated-to: 57487563d6208c04cbbeee3efa0280cb9166000a 2014-05-05 03:37:46 UTC changes: 100 files modified. Now, I may think that my repository is in a good state, but it is not, as one file is entirely missing, and fossil update will not restore it. If I do another update, Fossil shows that the rest of the missing artifacts were pulled down, but it still does not restore the files reported as having missing content. Also, it does not even show that this file is missing (e.g. either a MISSING file.1, nor a DELETE file.1), and if I make a change (say to file.1) and then checkin, the commit actually includes file.77 as a DELETED file even though there was no visual indication that this event would occur. I even tried a rebuild and it still will not restore the missing file. If I close/open the local repository it actually does finally bring back the file: $ fossil op ../clone.fossil file.77 project-name: <unnamed> repository: /tmp/clone/../clone.fossil local-root: /tmp/clone/ config-db: /home/amb/.fossil project-code: 43748f4be07be41523019a2c4532effbc3f5a02f checkout: 57487563d6208c04cbbeee3efa0280cb9166000a 2014-05-05 03:37:46 UTC parent: a2330f3775d7a939d9f0dd448bca639c1208505d 2014-05-05 03:30:47 UTC leaf: open tags: trunk comment: three (user: amb) checkins: 4 Notice that the UUID matches that which was received during the sync operation . Any ideas what might be going on here? Somtimes I've seen as much as 75% of the files end up with ``content missing.'' If I compile without [1317331eed] this particular problem doesn't happen, and all http_exchange errors are treated as fatal which result in an eventual ROLLBACK of the current round-trip. What have I missed? Perhaps with the per round-trip commit it is not really necessary to also have a COMMIT if the network drops that is implemented in [1317331eed]? Thanks, Andy -- TAI64 timestamp: 4000000053671747 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
