Thus said Rich Neswold on Thu, 08 May 2014 15:18:43 -0500: > I was thinking of attacking the problem a little higher up (since I'm > way too nervous touching the low-level stuff):
So did I initially, though my first thought was simply to have autosync try multiple times when failing (in the autosync-tries branch). Then Richard mentioned that it could be done by simply committing more frequently, and so I focused on that approach. I think it actually works quite well and I even added some protections to handle corner cases where a user might receive a partial sync, but then attempt to update/merge to a checkin that is not complete: http://www.fossil-scm.org/index.html/info/f2adddfe601d33c98974f9c645e8aceb9622aa86 One is free to force the update/merge if one desires with the --force-missing option. It would be interesting to get some actual testing with the repository that was mentioned would rollback after a 1GB sync to see how it does. Make sure it's a spare clone repository just in case, though I haven't seen any problems in my testing. Thoughts? Andy -- TAI64 timestamp: 40000000536c3088 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
