Thanks for that information. I was not aware that ticket changes involved artifacts also. I should have known that, but I’m still getting up to speed with fossil. A few months back when I first started using fossil I batch changed a bunch of tickets using SQL, I changed the value of the subsystem column.. since then I’ve gone in and edited many of the same tickets using the web ui and the subsystem value didn’t seem to revert back to anything, and everything seems fine, but now you have me a little worried that in some cases the artifacts of those tickets will be somehow out of sync with the SQL at some point in the future.
But thanks for the heads up, in the future if I am going to batch update a bunch of tickets I will use the fossil ticket command to do it in some way. On May 21, 2016, at 1:12 AM, Ron W <ronw.m...@gmail.com> wrote: > On Fri, May 20, 2016 at 10:43 AM, Steve Schow <st...@bstage.com> wrote: > I think perhaps you meant “commit” comment below? Its the commit comment > that needs to be tweaked, in theory, by the TH1…not the ticket itself. So > are you saying that modifying a commit comment requires that an artifact be > created with TH1 somehow, if even possible? > > To truly update the commit comment, you need to create a control artifact > that "attaches" an updated comment to the commit. This involves two things: > Create a string with the required "cards" (see > http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) then insert > the new artifact into the blob table. I don't know if the TH1 query function > will allow doing an insert or update. Have never tried. > > For the ticket table, I noticed in the admin page that there is a SQL insert > statement with comments that say we can add our own columns to it for > whatever purpose we want. It already has a status column which could be used > to store “working” status, but what I was thinking is I could stash something > in a different column that basically indicates its actually THE ONE that is > being worked on right now… I don’t think (?) any artifacts are needed for > putting info like that into the ticket table and using TH1 to check out that > data from the ticket table…it would not be any new records, but rather an > additional column to an existing row in ticket table. > > I think it would be ok to just update the one field in the ticket table. Just > be aware that a future update to the same ticket could cause fossil to > "forget" that change as there will be no artifact to "remind" it. > > Alternately, both the web UI and the Fossil command line can update fields in > a ticket, so a ticket change artifact would automatically be created. > > Which ever way the field gets set, a "SELECT tkt_uuid FROM ticket WHERE > working=yes;" should find and return the UUID of the currently "active" > ticket. > > However, it makes sense that actually updating the commit comment would be > more involved, and plenty of opportunities to get it wrong if there is no API > for such a thing in TH1…sounds like I would need have TH1 issue some SQL > that does it…and make sure the SQL is doing things right internally to create > this artifact you mentioned holding the updated commit comment. Yes? > > probabably easier and safer to just put this in the wrapper script I guess. > > Yes. But it might actually be possible to do it with just TH1 hook scripts. > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
