I tested a bit more by bypassing the mlink existence check for the
artifacts I know to be affected. This resulted in the events being created
but the reparents being ineffective. Artificial conditions, I know, but
this reproduces the symptoms of my original problem.
It looks like there are three cases:
1. Manifest artifact is visited first, at which point its event is created.
Reparent tag artifact is visited later, successfully updating the plink
table. All is well.
2. Reparent tag artifact is visited first, and mlink and plink are updated,
but no event is created. Manifest artifact is visited later, but since it's
already in mlink, no event is created. Check-in is not visible in the tree.
3. Reparent tag artifact is visited first, and plink are updated, but no
event is created. Since there happen to be no (changed?) files, no mlink is
created. Manifest artifact is visited later, and since there's no mlink,
the event is created. However, the plink table is updated using only the P
card in the original manifest, undoing the reparent tag. Check-in is
visible in the tree but has the wrong parent.
On Wed, Jun 20, 2018, 21:38 Andy Goth wrote:
> Even with the latest Fossil, I'm continuing to have problems with
> reparent. I'm also continuing to fail to produce a repeatable test case or
> even a repository I can share without endangering my livelihood. I've been
> trying for a couple years now, ever since reparent was first introduced.
> One would think a problem would be more likely to show itself in a stress
> test than in casual use, but here it's the opposite. A real Heisenbug.
> Today I resigned myself to the notion that I have to debug it on my own. I
> did find something, but I'm not sure it's even the issue I started out
> looking for, same as occurred recently for two issues with changing dates.
> I'm getting missing events in the database following rebuild or
> reconstruct, but the manifests and plinks and mlinks are all there. This
> results in holes in the timeline. I'm guessing the culprit is the test to
> only create the check-in event if there are no mlinks yet. Depending on
> artifact visitation order, this assumption might not work out too well. If
> the reparent tag is handled before the original check-in, will its event be
fossil-users mailing list