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 check-ins. 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. --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
