[fossil-users] commits from host A sometimes not seen on B

[Michai Ramakers]

Hello,

I'm probably doing somethng strange, but has anyone ever seen this behaviour:


1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

Perhaps relevant info:
- autosync=1 on both sides
- host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd
- both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386
- fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC
- fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC

I can't reproduce this, but if someone has ideas to try the next time
this happens I'd be happy to try. I can rebuild fossil on one or both
hosts, but I have the feeling this is something very basic.

Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

Michai

[Michai Ramakers]

Oh, perhaps useful: viewing the timeline on host S using the
web-interface (pointing to host S) at step (5) (or after step (6), not
sure) showed the commit I was expecting to see.

Post by Michai Ramakers
Hello,
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen
- autosync=1 on both sides
- host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd
- both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386
- fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC
- fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC
I can't reproduce this, but if someone has ideas to try the next time
this happens I'd be happy to try. I can rebuild fossil on one or both
hosts, but I have the feeling this is something very basic.
Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?
Michai

[Stephan Beal]

Post by Michai Ramakers
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

It sounds almost like you have autosync turned off - do 'up' and 'pull'
show any network traffic?

Post by Michai Ramakers
- autosync=1 on both sides

But you've already verified that.

Post by Michai Ramakers
Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

That doesn't sound wrong. If autosync is on there is rarely a need for
push/pull. Do an 'up' when you start working, to make sure you aren't
working from what would become a fork, and it will sync/push when you
commit (if autosync is on).

i hope someone can help you resolve this - i also suspect that the problem
will turn out to be something simple/silly.

[Michai Ramakers]

Post by Michai Ramakers
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

It sounds almost like you have autosync turned off - do 'up' and 'pull' show
any network traffic?

Tbh I forgot - the error-situation is gone now, sadly.

Post by Michai Ramakers
Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

That doesn't sound wrong. If autosync is on there is rarely a need for
push/pull. Do an 'up' when you start working, to make sure you aren't
working from what would become a fork, and it will sync/push when you commit
(if autosync is on).

Right.

If it comes up again, I'll try to keep it as-is, if that's possible,
and post it on here - who knows.

Michai

[Stestagg]

We had a similar situation last week:

Fossil server hosting many repos, two active clients on one repo.

Clients A and B were both working on the same branch simultaneously.

Client A commits (commit 1)
Client B tries to commit, gets conflict warning.
Client B runs fossil update
Client B commits successfully
Timeline on server shows two leaves with the same tag.
Client B never sees commit 1..
Running any combination of pull update rebuild does not work. The commit
message for 1 is not present in the database.

In the end, I resolved this by re-cloning from the server.

Note we've been doing parallel commits on the branch for a while. And this
has only happened once, both clients use auto sync.

I was going to chalk this up to cosmic particles or similar, but it sounds
as of it might be related.

Thanks

Steve

Post by Michai Ramakers

Post by Stephan Beal

Post by Michai Ramakers
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

It sounds almost like you have autosync turned off - do 'up' and 'pull'

show

Post by Stephan Beal
any network traffic?

Tbh I forgot - the error-situation is gone now, sadly.

Post by Stephan Beal

Post by Michai Ramakers
Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

That doesn't sound wrong. If autosync is on there is rarely a need for
push/pull. Do an 'up' when you start working, to make sure you aren't
working from what would become a fork, and it will sync/push when you

commit

Post by Stephan Beal
(if autosync is on).

Right.
If it comes up again, I'll try to keep it as-is, if that's possible,
and post it on here - who knows.
Michai
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Clive Hayward]

I have experienced a similar problem as Steve on several occasions. To fix
the problem I've been rebuilding the server repository and then merging on
the server. Then the clients can pull to get in sync.


Clive

Post by Stestagg
Fossil server hosting many repos, two active clients on one repo.
Clients A and B were both working on the same branch simultaneously.
Client A commits (commit 1)
Client B tries to commit, gets conflict warning.
Client B runs fossil update
Client B commits successfully
Timeline on server shows two leaves with the same tag.
Client B never sees commit 1..
Running any combination of pull update rebuild does not work. The commit
message for 1 is not present in the database.
In the end, I resolved this by re-cloning from the server.
Note we've been doing parallel commits on the branch for a while. And this
has only happened once, both clients use auto sync.
I was going to chalk this up to cosmic particles or similar, but it sounds
as of it might be related.
Thanks
Steve

Post by Michai Ramakers

Post by Stephan Beal

Post by Michai Ramakers
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

It sounds almost like you have autosync turned off - do 'up' and 'pull'

show

Post by Stephan Beal
any network traffic?

Tbh I forgot - the error-situation is gone now, sadly.

Post by Stephan Beal

Post by Michai Ramakers
Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

That doesn't sound wrong. If autosync is on there is rarely a need for
push/pull. Do an 'up' when you start working, to make sure you aren't
working from what would become a fork, and it will sync/push when you

commit

Post by Stephan Beal
(if autosync is on).

Right.
If it comes up again, I'll try to keep it as-is, if that's possible,
and post it on here - who knows.
Michai
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Michai Ramakers]

did any of you (Steve/Clive) by any chance try committing once more (a
dummy-change or similar) on what Steve has named client A (the client
whose commit is never seen by the other host)?
(And if so, did both it and the missing commit show up?)

Michai

[Clive Hayward]

Michai,

In more than one instance a subsequent commit was performed on one of the
clients (unaware that there was an issue). That commit was visible to the
other client only after the server repository was rebuilt.

Clive

Post by Michai Ramakers
did any of you (Steve/Clive) by any chance try committing once more (a
dummy-change or similar) on what Steve has named client A (the client
whose commit is never seen by the other host)?
(And if so, did both it and the missing commit show up?)
Michai
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Stephan Beal]

Post by Clive Hayward
Michai,
In more than one instance a subsequent commit was performed on one of the
clients (unaware that there was an issue). That commit was visible to the
other client only after the server repository was rebuilt.

i've had a couple cases which sound similar but were explainable. i would
make a commit, the push would fail because my network was out or whatever,
and i wouldn't notice it. Later on i'd wonder where my commit was. That's
happened to me a handful of times over the years.

[Clive Hayward]

Stephan,

Although I haven't been able to consistently reproduce the errors. These
were definitely not network errors.

The steps involve.

1) Client A makes a commit.
2) Client B makes a commit - but is warned that they will fork.
3) Client B updates - but doesn't appear to get Client A's commit.
4) Client B commits with no error and the server forks.
5) Client C updates but only gets Client A or B's commit but not both.

At this point fossil rebuild on the server. Clients can update and can see
the other leafs.

Post by Stephan Beal

Post by Clive Hayward
Michai,
In more than one instance a subsequent commit was performed on one of the
clients (unaware that there was an issue). That commit was visible to the
other client only after the server repository was rebuilt.

i've had a couple cases which sound similar but were explainable. i would
make a commit, the push would fail because my network was out or whatever,
and i wouldn't notice it. Later on i'd wonder where my commit was. That's
happened to me a handful of times over the years.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal

[Stephan Beal]

Post by Clive Hayward
5) Client C updates but only gets Client A or B's commit but not both.

All i can say to that is, "yeah, that's weird." Unfortunately not terribly
helpful.

[Richard Hipp]

I think there is a bug in the sync algorithm that sometimes causes it to
quit before both sides are fully synced up. But I don't yet have a
reproducible test case, so it is a hard problem to fix.

If you find a pair of repositories that are not fully syncing, please do
this:

(1) Make backup copies of the repositories on both sides of the exchange
and make them available to me for debugging.

(2) Run "fossil sync --verily" which is a heavy-duty sync that has a
simpler design that uses more bandwidth but which is also much more likely
to run to completion. A single "fossil sync --verily" is probably
sufficient to get the two repos talking again after which ordinary syncs
(without the --verily option) should be sufficient again.

[Clive Hayward]

Richard,

Would love to share repositories but would be violating my IP agreements:(
So I'll need to try and trigger the problem with non-business data.

Thanks for the reference to "fossil sync --verily"

Post by Richard Hipp
I think there is a bug in the sync algorithm that sometimes causes it to
quit before both sides are fully synced up. But I don't yet have a
reproducible test case, so it is a hard problem to fix.
If you find a pair of repositories that are not fully syncing, please do
(1) Make backup copies of the repositories on both sides of the exchange
and make them available to me for debugging.
(2) Run "fossil sync --verily" which is a heavy-duty sync that has a
simpler design that uses more bandwidth but which is also much more likely
to run to completion. A single "fossil sync --verily" is probably
sufficient to get the two repos talking again after which ordinary syncs
(without the --verily option) should be sufficient again.
--
D. Richard Hipp

[Clive Hayward]

Richard,

Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC.
Command: "fossil
sync --verily"

Result: "unknown repository: --verily"

Grepping the code I see the "--verily" option looks only applicable to the
"fossil scrub" command.

Is there a particular version that supports "--verily" for sync.

Thanks,
Clive

Post by Clive Hayward
Richard,
Would love to share repositories but would be violating my IP agreements:(
So I'll need to try and trigger the problem with non-business data.
Thanks for the reference to "fossil sync --verily"

Post by Richard Hipp
I think there is a bug in the sync algorithm that sometimes causes it to
quit before both sides are fully synced up. But I don't yet have a
reproducible test case, so it is a hard problem to fix.
If you find a pair of repositories that are not fully syncing, please do
(1) Make backup copies of the repositories on both sides of the exchange
and make them available to me for debugging.
(2) Run "fossil sync --verily" which is a heavy-duty sync that has a
simpler design that uses more bandwidth but which is also much more likely
to run to completion. A single "fossil sync --verily" is probably
sufficient to get the two repos talking again after which ordinary syncs
(without the --verily option) should be sufficient again.
--
D. Richard Hipp

--
Clive Hayward

[Richard Hipp]

Post by Clive Hayward
Richard,
Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC. Command: "fossil
sync --verily"
Result: "unknown repository: --verily"
Grepping the code I see the "--verily" option looks only applicable to the
"fossil scrub" command.
Is there a particular version that supports "--verily" for sync.

That option is unreleased, so you'll have to compile from sources. That is
easier than you might imagine. Instructions here:
http://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki

[Doug Franklin]

Post by Richard Hipp
That option is unreleased, so you'll have to compile from sources. That
http://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki

It /must/ be. Even /I/ managed it! :)

[Donny Ward]

Hey Richard,

I get the same problem every once in awhile. Many times actually. I
consider myself a heavy fossil user. My most active repository has 1087
checkins all made by me.

I once submitted a ticket about it here:
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext

I have not noticed a pattern with the syncing problems. Going by feel, it
feels like it occurs most frequently when I create a new branch, or if I
edit a check-in comment.

Also keep in mind that I rarely if ever have had "sync errors". After every
commit I would look at the remote repository to see if all the changes
synced and they always do, except for these few cases.

Also note that I always have auto-sync turned on. I used to host my
repositories on a Linux VPS. I have since moved to Chisel and still have
encountered sync problems. One time when the problem occured on my Linux
VPS, I solved the problem by rebuilding the repository on the VPS side (the
"host" repository). I dug around the source code of Fossil briefly to try
and figure out the problem, and while I did not pinpoint it, I believed at
the time that the issue had to do with the usage of clustered and
unclustered artifacts. If I understand correctly, the used of these
clusters is for a syncing optimization. However once I saw that you
committed the --verily option, I stopped pursuing the problem because I was
fairly confident that --verily solves the issue. Since my repository is
hosted on Chisel, I will not find out until the next version is released
and Chisel updates to that version.

Also note that in ALL cases, the syncing problem can be solved by recloning
the host repository. But I would prefer not to do that every time. I only
used the fossil rebuild solution one time so I can't confidently say that
it fixed the problem. And since I can't rebuild repositories on Chisel I
can't try it with my current syncing problem.

The problems have occured with and without HTTPS.

So right now I actually have the syncing problem again. I created a new
branch where I committed the entire source code to FreeType. This was done
in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind
I have autosync always on) and it failed to pull the new branch; it's
missing entirely from the timeline. It's also missing from my Macbook as
well.

So Mr. Hipp if you're interested, I can send you a copies of my repository
to analyze and debug. However I would also need to get the current
maintainer of Chisel to email me an untouched copy of my repository as it
exists on that site right now. Does anyone have contact info for Chisel?
The site still has James Turner's name on it.

I would very much like for this bug to be fixed. Though --verily looks
promising.

Donny Ward

[B Harder]

Post by Donny Ward
Hey Richard,
I get the same problem every once in awhile. Many times actually. I

consider myself a heavy fossil user. My most active repository has 1087
checkins all made by me.
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext

Post by Donny Ward
I have not noticed a pattern with the syncing problems. Going by feel, it

feels like it occurs most frequently when I create a new branch, or if I
edit a check-in comment.

Post by Donny Ward
Also keep in mind that I rarely if ever have had "sync errors". After

every commit I would look at the remote repository to see if all the
changes synced and they always do, except for these few cases.

Post by Donny Ward
Also note that I always have auto-sync turned on. I used to host my

repositories on a Linux VPS. I have since moved to Chisel and still have
encountered sync problems. One time when the problem occured on my Linux
VPS, I solved the problem by rebuilding the repository on the VPS side (the
"host" repository). I dug around the source code of Fossil briefly to try
and figure out the problem, and while I did not pinpoint it, I believed at
the time that the issue had to do with the usage of clustered and
unclustered artifacts. If I understand correctly, the used of these
clusters is for a syncing optimization. However once I saw that you
committed the --verily option, I stopped pursuing the problem because I was
fairly confident that --verily solves the issue. Since my repository is
hosted on Chisel, I will not find out until the next version is released
and Chisel updates to that version.

Post by Donny Ward
Also note that in ALL cases, the syncing problem can be solved by

recloning the host repository. But I would prefer not to do that every
time. I only used the fossil rebuild solution one time so I can't
confidently say that it fixed the problem. And since I can't rebuild
repositories on Chisel I can't try it with my current syncing problem.

Post by Donny Ward
The problems have occured with and without HTTPS.
So right now I actually have the syncing problem again. I created a new

branch where I committed the entire source code to FreeType. This was done
in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind
I have autosync always on) and it failed to pull the new branch; it's
missing entirely from the timeline. It's also missing from my Macbook as
well.

Post by Donny Ward
So Mr. Hipp if you're interested, I can send you a copies of my

repository to analyze and debug. However I would also need to get the
current maintainer of Chisel to email me an untouched copy of my repository
as it exists on that site right now. Does anyone have contact info for
Chisel? The site still has James Turner's name on it.

Post by Donny Ward
I would very much like for this bug to be fixed. Though --verily looks

promising.

Post by Donny Ward
Donny Ward
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Michai Ramakers]

I get the same problem every once in awhile. Many times actually. I consider
myself a heavy fossil user. My most active repository has 1087 checkins all
made by me.
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext
...

That sounds familiar. For the record, let me say I never (ever) make
branches; all work here is done on trunk.

The ticket you mention is 'fixed' stating a workaround like I did
here; I'm not sure that is how it should be. (Not that reopening the
ticket magically fixes the problem, but you give detailed and probably
useful information there.)

Michai

[Chad Perrin]

Post by Michai Ramakers

I get the same problem every once in awhile. Many times actually. I consider
myself a heavy fossil user. My most active repository has 1087 checkins all
made by me.
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext
...

That sounds familiar. For the record, let me say I never (ever) make
branches; all work here is done on trunk.

In the repository where a fellow developer and I have seen this problem,
there have been no intentional branches made, so add one to the numbers
for this condition of the problem arising.

Post by Michai Ramakers
The ticket you mention is 'fixed' stating a workaround like I did
here; I'm not sure that is how it should be. (Not that reopening the
ticket magically fixes the problem, but you give detailed and probably
useful information there.)

Indeed. The "fix" is in the behavior of one person's repository, and
not in the intermittently manifesting issue with the operation of Fossil
itself.

[Richard Hipp]

Post by Chad Perrin

Post by Michai Ramakers
That sounds familiar. For the record, let me say I never (ever) make
branches; all work here is done on trunk.

In the repository where a fellow developer and I have seen this problem,
there have been no intentional branches made, so add one to the numbers
for this condition of the problem arising.

The sync protocol for Fossil (
http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no attention
to check-ins or branching or tags or any other structure in the
repository. The sync logic looks at the repository as an unordered bag of
artifacts and it tries to make both participating repositories have the
same set of artifacts. It treats the artifacts as opaque binary blobs.

So, whatever this bug is, I'm guessing it does not have anything to do with
branching.

FWIW, the --verily option to "fossil sync" causes both participates to send
"igot" cards for every artifact they hold (which can be tens or hundreds of
thousands of artifacts). This seems to be sufficient to get both sides
back into sync with one another. The downside is that with hundreds of
thousands of artifacts, sending all those igot cards takes a lot of network
traffic.

The bug must be in one of the shortcuts by which Fossil normally avoids
sending its complete set of igot cards.

[Stestagg]

One thing to add here, is that when this happened for us, I had two
different clones, one in a VM, and one on my workstation, and both of these
couldn't see the 'faulty' commit until I re-cloned the repo (on both).

So it seems to be a feature of the commit (or the copy that hits the
server) rather than that of a particular checkout.

Steve

Post by Richard Hipp

Post by Chad Perrin

Post by Michai Ramakers
That sounds familiar. For the record, let me say I never (ever) make
branches; all work here is done on trunk.

In the repository where a fellow developer and I have seen this problem,
there have been no intentional branches made, so add one to the numbers
for this condition of the problem arising.

The sync protocol for Fossil (
http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no
attention to check-ins or branching or tags or any other structure in the
repository. The sync logic looks at the repository as an unordered bag of
artifacts and it tries to make both participating repositories have the
same set of artifacts. It treats the artifacts as opaque binary blobs.
So, whatever this bug is, I'm guessing it does not have anything to do
with branching.
FWIW, the --verily option to "fossil sync" causes both participates to
send "igot" cards for every artifact they hold (which can be tens or
hundreds of thousands of artifacts). This seems to be sufficient to get
both sides back into sync with one another. The downside is that with
hundreds of thousands of artifacts, sending all those igot cards takes a
lot of network traffic.
The bug must be in one of the shortcuts by which Fossil normally avoids
sending its complete set of igot cards.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Chad Perrin]

Post by Michai Ramakers
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen
- autosync=1 on both sides
- host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd
- both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386
- fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC
- fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC

Just to add some anecdotal data to this . . .

I've seen this behavior recently as well, in very similar circumstances.
The major difference has been that both clients have autosync turned
off, and do a manual sync before hacking on code, and either a pull
before pushing commits or a manual sync. Running "fossil update" after
a sync or pull that brings in changes that, in turn, do not show up in
the client's checkout directory does not solve the problem, if I recall
correctly. It has only happened a couple of times, and both times was
fixed by a merge on one side or the other or a reclone.

Unfortunately, I have not been able to determine whether any particular
pattern of using manual sync or pull has an effect on this. Note that,
as I said, it has not happened much, so I have not had much opportunity
to identify the conditions specific to the manifestation of the problem
with any certainty, apart from what I have mentioned above, which is why
I had not composed a question myself about this issue yet. This
situation concerns us because the workflow we use may lead to problems
if a failure of Fossil to properly deliver commits leads to new code
being added in a non-merged way without developers noticing.

The server is running Fossil v1.26 (from ports) on FreeBSD 9.0 amd64,
one client is running Fossil v1.26 (from ports) on FreeBSD 9.1 amd64,
and the other client is running an unknown version of Fossil (from
packages) on Arch Linux amd64, I believe, though I will check on the
Fossil version when that developer is available and double-check the
installed OS with him as well, and share that information if it is
deemed relevant.