On Thu, Jun 12, 2014 at 02:46:09PM -0400, Eric Rubin-Smith 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.
I got same issue recently and I'm also using WAL mode. My topology is
like this:
M: Master
(Linux and main development machine, db in WAL mode)
C1: clone 1 (autosync with Master)
(windows laptop through slow connection)
C2: clone 2 (autosync with Master)
(Linux, on LAN with fast connection)
BK: clone 3 Offsite backup repo
(no checkout, master push to it frequently)
When the problem happens (e.g. C1 don't get latest change that was
pushed by C2), I pull from "BK" instead and it works. Then it's okay for
the next sync..
(I never try the --verily option, I was not aware of it)
In your example above, have you try to pull directly changes of C1 from
C2 ?
example:
fossil pull http://user@C1/path/to/repo.fossil --once
[snip]
Hopefully this will give some hints to track the problem..
--
Martin G.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
