I have a repository with 4 "reparented" check-ins (to skip over
unwanted check-ins), which were later merged into other branches.

When rebuilding the repository, I noticed that the number of check-ins
on the /stats webpage had dropped by 4, and the /bloblist page showed
"unknown" instead of "check-in on ..." as the description for the 4
affected check-ins. This resulted in a broken /timeline view, with the
4 "reparented" check-ins no longer visible on screen, but with lines
leaving the screen at the top and bottom, to supposedly join the lost

I also noticed that the RIDs (as shown in the first column of the
/bloblist page) were changed by the rebuild, not randomly, but only
with positive offsets of small numbers.

When cloning the repository from the server, and performing a rebuild
on the local copy, the problem does not occur. But it happens when
rebuilding the repository on the server, or when downloading and
rebuilding it locally.

Is the "reparent" action somehow linked to the RID, and is it broken
by the RID changes? Or are RIDs expected to change, because other
artifacts such as "clusters" are sometimes interspersed?

The problem is reproducible with both Fossil 1.36 and Fossil 2.2, and
is independent of the "hash-policy" setting (my initial suspicion).

The following test case (Windows batch file) is close to the situation
in my repository with many edits of check-in comments, and merges of
"reparented" check-ins, but it does not exhibit the problem after
rebuilding (neither with Fossil 1.36 nor 2.2):

fossil init test.fossil
fossil open test.fossil
echo m1.1>sample.txt
@echo *************************************** & pause
fossil add sample.txt
fossil ci -m m1.1 --tag m1.1 --branch br1 --no-warnings
fossil amend m1.1 -m m1.1-edited
echo m1.2>sample.txt
@echo *************************************** & pause
fossil ci -m m1.2 --tag m1.2 --no-warnings
fossil amend m1.2 -m m1.2-edited
echo m1.3>sample.txt
@echo *************************************** & pause
fossil ci -m m1.3 --tag m1.3 --no-warnings
fossil amend m1.3 -m m1.3-edited
echo m1.4>sample.txt
@echo *************************************** & pause
fossil ci -m m1.4 --tag m1.4 --no-warnings
fossil amend m1.4 -m m1.4-edited
echo m1.5>sample.txt
@echo *************************************** & pause
fossil ci -m m1.5 --tag m1.5 --no-warnings
fossil amend m1.5 -m m1.5-edited
fossil co m1.1
echo m2.1>>sample.txt
@echo *************************************** & pause
fossil ci -m m2.1 --tag m2.1 --branch br2 --no-warnings
fossil amend m2.1 -m m2.1-edited
@echo *************************************** & pause
fossil merge br1 --integrate
fossil ci -m m2.2 --tag m2.2 --no-warnings
fossil amend m2.2 -m m2.2-edited
echo m2.3>>sample.txt
@echo *************************************** & pause
fossil ci -m 2.3 --tag m2.3 --no-warnings
fossil amend m2.3 -m m2.3-edited
fossil reparent m1.5 m1.3
@echo *************************************** & pause
fossil merge m1.4
fossil ci -m m2.4 --tag m2.4 --no-warnings --allow-conflict
fossil amend m2.4 -m m2.4-edited

I'm sorry I have no simple reproducible example. If this is not an
already obvious and straight forward problem for the Fossil
development team, and is really worth investigation (after all, use of
the "reparent" command is discouraged in the online help), I'm willing
to share my problematic repository with a small group of developers,
if I can be assured it will be deleted and not be kept in a long-term
test case/bug database, after research.

fossil-users mailing list

Reply via email to