It may be that you need to replace the "one giant file" in the below scenario with "a great many files that as a whole take up a lot of bytes". I don't remember. Sorry. :-/
On Thu, Jun 12, 2014 at 2:46 PM, Eric Rubin-Smith <eas....@gmail.com> wrote: > 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
