Hello, I've been trying to investigate the problem that has been reported over time and so far I haven't been able to reproduce it or come to any conclusive decision regarding what might be the cause. When (in Fossil versions) did this problem first get noticed or start happening?
Thanks to Donny Ward, we at least have one Fossil repository that seems to reveal one possible cause. For whatever reason, one of the checkin artifacts in the timeline did not make it into a cluster. I've been trying to determine how this could come about and so far can only see a few possibilities (none of them a solid cause): 1) When the content was received for the checkin, something failed to put the artifact rid in the unclustered table. 2) The artifact rid was in the unclustered table, but when create_cluster() ran it prematurely removed it from the table. 3) The content was originally private (private content does not get put into unclustered table) and somehow got marked as public. 4) There is a bug in this loop that sometimes prematurely removes artifact rids from the unclustered table: http://www.fossil-scm.org/index.html/artifact/37f2afbbd186bf5cef90c57b7fa1acd7097977cd?ln=692,701 I haven't been able to find any way that 1 could happen. The only way I can imagine 2 could happen is if there is a phantom for the checkin artifact, the content hasn't yet arrived, and create_cluster() is run which will cause the rid of the artifact to be removed from the unclustered table and it will never make it into a cluster. I'm not sure how this could happen, but it is potentially a problem (I started working on this particular scenario in the cluster-changes branch). For 3, I see that there is some code that will remove rids from the private table if they are received and made public: http://www.fossil-scm.org/index.html/artifact/37f2afbbd186bf5cef90c57b7fa1acd7097977cd?ln=172 http://www.fossil-scm.org/index.html/artifact/ef8da0287cc50af631daec6886f56b458aa1e4fc?ln=738,745 But if they are in the private table, then necessarily they will not have been added to the unclustered table: http://www.fossil-scm.org/index.html/artifact/ef8da0287cc50af631daec6886f56b458aa1e4fc?ln=572,575 http://www.fossil-scm.org/index.html/artifact/ef8da0287cc50af631daec6886f56b458aa1e4fc?ln=596,598 Which means that they will never show up in a cluster (even after made public) and they will not be in the unclustered table. So why does the content_make_public() function exist? Is it possible to switch private content from private to public? I didn't think it was, but perhaps this is also one potential way that a checkin could fail to sync if it happens because removing the rid from the private table won't put the rid into the unclustered table. Finally, for option 4, this block of code only kicks in for large unclustered tables where the number of rows currently added to a new cluster is >=800 and the number of artifacts not yet clustered is >rows+100. Again, I cannot see where there is any problem, but a number of people have indicated that it happens when there are a lot of files in the checkin---this was also the case of Donny's a9b134481708 artifact. It was a checkin that had 1251 F-cards in the manifest which means there were probably a lot of entries in unclustered until the next time a pull happened. I have tried to reproduce it with various large numbers of commits and haven't yet been able to cause it. At any rate, Donny, were you doing anything with private content for checkin a9b134481708 in your repository? Or did you have any kind of automated pull that might have coincided with the time that the checkin was being committed to the repository? Did you shun the checkin artifact and then unshun it? Other thoughts? Should cluster artifacts have a D-card in them? Might make it easier to correlate the timeline checkins with when they get created. Thanks, Andy -- TAI64 timestamp: 4000000053c18e7d _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
