Post by bch
Has the Ryerson Bug be characterised?
Basically, versions of Fossil 1.27 and older, assumed that the first rid
in the blob table would always be a checkin. This was true because the
first thing fossil new did was to create a bogus checkin with a comment
of ``initial empty check-in'', however, there is nothing special about
the ``initial empty check-in'' except that it was always the first (e.g.
rid=1) in the database. That meant that it would also be first to be
offered up during cloning, so all clones would also have a checkin in
their local database for rid=1. Then, when this Fossil was open, it
would open it beginning with whatever was in rid=1.
A change was made to remove the need for the ``initial empty check-in''
which allowed users to make a repository which had the first checkin be
their own, however, due to the way checkins are made, this now meant
that rid=1 would not be a checkin. So when the older versions of Fossil
cloned the repository, it would try to open the newly cloned Fossil with
rid=1, but rid=1 was actually no longer a checkin, but another type of
artifact (most likely a file).
After opening, no files would be seen (clearly because a file manifest
does not have files, it has content), and if any commits were made at
this time, they would have a P-card which points to the file, not to a
checkin. This would result in a broken timeline in the UI.
The requirement, specifically, is that the first artifact that the
server sends during a clone, must be a checkin, or older Fossil clients
will end up in this state.
As far as I can tell, this would appear to not have resulted in actual
data loss, only some strange problems with the timeline and incorrect
manifests. Upgrading to a newer Fossil makes the content available, but
there is still the broken timeline and currently Fossil has no way to
reconnect the lineage in the timeline (though there is an option planned
for altering the parentage).
In addition, it's possible that this problem does still exist
for repositories that have undergone fossil deconstruct reconstruct
operations because as far as I can tell this operation does not
guarantee that rid=1 will be a checkin in the newly created repository,
however, this is an uncommon procedure. But if reconstruct did place
a non-checkin as rid=1, then older clients would not be able to
successfully use the clone.
Just to be clear, it is still possible to have multiple DAGs in a Fossil
using the fossil open --empty. This is allowed because doing so does not
create a repository that exhibits the problem described above (because
presumably the repository already has the ``initial empty check-in''
which will satisfy the requirement above).
Let me know if this needs further clarification.
TAI64 timestamp: 400000005505a755