Thus said Tontyna on Fri, 13 Mar 2015 13:12:25 +0100: > A tricky SQL statement could probably create the required records...
While no content was lost, the relationship appears to have been lost, which is why the timeline cannot figure out how to draw it. Specifically, the problem appears to be that the manifest for the checkin on the alternate tree has an incorrect P-card. The P-card for the checkin is actually not a checkin artifact, but rather is a file artifact. For example, in a test repository where I caused the issue (following your instructions), the first checkin after cloning generates a manifest like: C This\sis\sa\stest. D 2015-03-12T16:24:08.929 F file 914a1602b6193e4b66d78b1b8ffa7cf599dabfc8 P 79a816e5ee1e7139d7cd4326a713c16c16dbe236 R e28bf5671577b991b7edb68bd78fd78f U amb Z ee6e8bcef3bf4a9d39d755082f5c15d4 But 79a816e5ee1e7139d7cd4326a713c16c16dbe236 is actually the previous revision of the file itself and not the previous checkin. Here is the manifest of the original first-time commit when the repository was empty: C one D 2015-03-12T16:16:53.699 F file 79a816e5ee1e7139d7cd4326a713c16c16dbe236 R 2e2b846407951e4e86de07454ab860f1 T *branch * trunk T *sym-trunk * U amb Z e0783afde0ee3f78d55affc6494d3f50 Notice that the hash for the F-card and the hash for the P-card from the second checkin are the same. So while Fossil 1.27 did successfully add the content (no content was lost) it picked the wrong file to generate the P-card. I don't know of any way to repair this. Andy -- TAI64 timestamp: 4000000055031610 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
