Thus said Venkat Iyer on Fri, 21 Oct 2016 21:22:13 -0700: > I tried to find where that +icomment was coming from without much > success. Any advice appreciated. Fossil sqlite3 hackery is fine.
fossil ticket ls fields shows icomment in my database. It looks like there should have been a transaction wrapped around whatever ``fossil ticket set'' does because when I tried your command it actually returned an SQL error, but then apparently also committed the changes, in spite of the error: $ fossil ticket change 0f3bfc6c55 +icomment "ivenkat added on > 2016-10-21.18:50:20 PDT:<br> > script checked in to [1a8ae0e34f]" SQLITE_ERROR: table ticketchng has no column named +icomment fossil: table ticketchng has no column named +icomment INSERT INTO ticketchng(tkt_id,tkt_mtime,"+icomment",tkt_rid)VALUES(1,:mtime,'ivenkat added on 2016-10-21.18:50:20 PDT:<br> script checked in to [1a8ae0e34f]',3) So now I've got something in my database that is causing problems because it looks like there was something partially committed. This failed because +icomment apparently was not interpreted as the documentation indicates it should be: If you use +FIELD, the VALUE is appended to the field FIELD. Seems like a bug. It also seems like a bug that the transaction wasn't rolled back on the initial attempt to insert the data. So two bugs. > I tried to find where that +icomment was coming from without much > success. Any advice appreciated. Fossil sqlite3 hackery is fine. I'm not sure this will work, but I think it should be possible to delete the bad artifact from the blob table. You'll have to identify which one it is. You could use ``fossil deconstruct'' and then find the file that has a ``J +icomment'' card in it. Or you could use something like: $ fossil test-describe-artifacts d87cb4d455c100a2 unknown ec6692e5d6e071e5 check-in on 2016-10-22 18:53 ad17035460356de4 ticket 51bf48d3fd8eaf226756b 8adb146462e68585 ticket 51bf48d3fd8eaf226756b 86d1022b4d5d6b7f ticket 51bf48d3fd8eaf226756b 8a3bd4261e6175f0 ticket 51bf48d3fd8eaf226756b Notice that the first artifact in my list is unknown, and it just happens to be the bogus record. If you have many such unknown artifacts, it might be more work this way. At any rate, then delete it: $ fossil art d87cb4d455c100a2 D 2016-10-22T18:57:16.614 J +icomment funziona\snumero\sdue K 51bf48d3fd8eaf226756ba0037a8fed7ac5c165c U amb Z 2e583adf82bab42b06777748188b78fb $ fossil info d87cb4d455c100a2 uuid: d87cb4d455c100a208a298c98f8ae06d2235d1f7 printf "DELETE FROM blob WHERE uuid = 'd87cb4d455c100a208a298c98f8ae06d2235d1f7';" | fossil sql And now it rebuilds: $ fossil rebuild 100.0% complete... I think the most important bug fix is to ensure that the ticket changes are wrapped in a transaction to avoid this happening in the future. Then figuring out what's wrong with +icomment. Andy -- TAI64 timestamp: 40000000580bbd40 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
