I believe I have seen this issue. It's been a while, but here is the scenario as far as I can recollect:
1. Assume there are three repo copies in a "master/client" topology: M, C1, and C2. M is the master, and C1/C2 are clones of the master (meaning that C1 and C2 don't know about each other; they always push to and pull from M). No proxies anywhere. 2. M, C1, and C2 are all separated by low-bandwidth, high-latency links, which causes syncs to take a long time. 3. C1 creates a giant file, checks it in, and pushes it to M. The push completes. 4. C2 begins a pull. 5. During C2's pull, C1 creates a small file, checks it in, and pushes it to M. 6. A long time later, C2's pull completes. 7. C2 initiates another pull. But M does not report the new small file, so C2 does not see the new file. In my case, I worked around the issue by creating yet another artifact from C1. This seems to have caused M and/or C2 to sort themselves out. I have no idea how the sync code works, but at the time I suspected that there is some sort of optimization involving timestamps, and a slow sync can cause that code to get confused and miss some artifacts. May or may not have an interaction with sqlite's WAL setting (which allows reads concurrent with one write, if memory serves). Anyway, hopefully that won't send you on too big of a goose chase. On Thu, Jun 12, 2014 at 1:54 PM, Stephan Beal <sgb...@googlemail.com> wrote: > On Thu, Jun 12, 2014 at 6:00 PM, Andy Bradford <amb-fos...@bradfords.org> > wrote: > >> This has been mentioned before a few times, but so far, nobody has been >> able to provide enough details to reproduce it and none of the Fossil >> devs have seen it. >> > > It's come up 3 or 4 times the past year, IIRC. i _might_ have seen it > once, but i might have just forgotten to pull in that case. Nobody's been > able to consistently reproduce it, nor come up with a hint about where it > may lie. i _think_ (but my memory's far from perfect) we ruled out a > caching proxy server in the middle in at least one case. > > >> If it happens again will you provide the output of both the commit from >> one machine and the update from the second? At least that would be a >> start. >> > > +1 > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > _______________________________________________ > 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
