Dr Hipp, Thanks very much for the detailed explanation! Ok, it is probably best in my situation if I leave autosync permanently off.
Your clarification about the inherent integrity of the database has greatly reassured me. One extra question: You have mentioned about possible schema changes in the database in a later version of Fossil. Ok, I have my online repository. If someone installs Fossil by downloading your latest binary executable, and then clones my repository, isn't there a potential problem, if I have been working with an older Fossil executable? Regards, Barry Kauler On 11/13/09, D. Richard Hipp <d...@hwaci.com> wrote: > > On Nov 13, 2009, at 7:30 AM, Barry Kauler wrote: > >> Continuing from my previous post: >> >> Continuing from before, I attempted a second time, this time the >> Internet connection is "good": >> >> # fossil commit -m "added file PKGS_MANAGEMENT" --nosign >> Autosync: http://bkhome.org/fossil/woof.cgi >> Bytes Cards Artifacts Deltas >> Send: 130 1 0 0 >> Received: 230 5 0 0 >> Total network traffic: 323 bytes sent, 466 bytes received >> fossil: nothing has changed >> >> I found that file PKGS_MANAGEMENT was not added to the repository, so >> the failed 'commit' had also cleared the 'add'. > > There are two autosyncs on a commit. The first autosync is really > just a "pull". It checks to see if somebody else has already committed > changes against the same version you are committing against and hence > that you are about to fork. If the first autosync fails, the commit > does not occur. It really shouldn't cancel your "add" (that seems > like a bug) but at the same time, information you have previously > committed should remain intact. > > The second autosync is a push that sends the newly committed content > back up to the remote repository. The second autosync occurs after > the commit was successful and so if the second autosync fails, it > should be sufficient to simply rerun "sync" to push the contents again. > > >> >> So I had to do the whole thing again, and this time it worked: >> >> # fossil add PKGS_MANAGEMENT >> ADDED PKGS_MANAGEMENT >> # fossil commit -m "added file PKGS_MANAGEMENT" --nosign >> Autosync: http://bkhome.org/fossil/woof.cgi >> Bytes Cards Artifacts Deltas >> Send: 130 1 0 0 >> Received: 230 5 0 0 >> Total network traffic: 322 bytes sent, 466 bytes received >> New_Version: 8db611a1f647f81834a5df1b7a59959c80a25f5a >> Autosync: http://bkhome.org/fossil/woof.cgi >> Bytes Cards Artifacts Deltas >> Send: 8663 9 2 0 >> Received: 322 7 0 0 >> Total network traffic: 4649 bytes sent, 514 bytes received >> >> Regards, >> Barry Kauler >> >> >> On 11/13/09, Barry Kauler <bkau...@gmail.com> wrote: >>> Hi guys, >>> I'm enjoying playing with Fossil, but I've run into a problem... >>> >>> I have a satellite Internet connection. Apart from the incredible >>> latency (over 1 second, testing with ping), my connection "freezes" >>> every now and again. >>> >>> This "freezing" problem has something to do with communication with >>> the satellite, so it's not just my system. What happens is that the >>> Internet is "dead" for awhile, maybe a minute, maybe longer. >>> >>> Anyway, I did a 'fossil commit' just as one of these "freezes" >>> occurred, and I got this: >>> >>> # fossil commit -m "added file PKGS_MANAGEMENT" --nosign >>> Autosync: http://bkhome.org/fossil/woof.cgi >>> Bytes Cards Artifacts Deltas >>> Send: 130 1 0 0 >>> >>> The freeze was temporary, a matter of seconds later the Internet was >>> working again. However the 'fossil commit' operation was hung. >>> >>> I had to do a CTRL-C to terminate it. >>> >>> My question: Fossil should not be assuming a "perfect" Internet >>> connection should it? Shouldn't a push (or pull) have a timeout, and >>> maybe a retry? Just to hang is not very good. >>> >>> Then there's the question, as I had to terminate it with a CTRL-C, is >>> there any kind of assurance that what did arrive at the remote >>> repository, if anything, is not partial and thus corrupted? >>> >>> If I use a program like wget, it does have fallback code to handle >>> this kind of situation. >>> >>> Regards, >>> Barry Kauler >>> >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > D. Richard Hipp > d...@hwaci.com > > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
