[fossil-users] Branch and tag metadata
I'm thinking I might want the ability to describe branches and tags separate from the check-in comments. Maybe a wiki page with the same name as the branch or tag would serve the purpose, then in the wiki page there could be links to tickets or whatever else is needed to describe what is going on. But that's not quite enough. Or rather, it's sometimes too much. I'd like to summarize the purpose of the branch or tag. The name kind of does that, but it has to be very terse for ease of typing. In my case I'd like to copy the associated ClearQuest activity title. Right now I'm using it as the check-in comment for when the branch ultimately gets integrated to trunk. That works, but in order to get the title I have to click on the tag in the tag list. Would be good to see them all in one page (or a filtered subset thereof) so I can search for keywords. Well actually there's already a fulltext search, but I don't think there's a way to limit it to only check-ins to trunk or to do other filters, e.g. only for check-ins having tags matching a glob pattern. Plus the check-in comment trick doesn't work to describe branches that haven't been integrated to trunk yet. The check-in comments on branches just describe the actual changes being performed, and I don't feel good about also shoehorning the activity titles in there. Maybe each branch could start with an empty check-in just to hold the title. Doesn't the "branch new" command do that? Oh wait, it doesn't allow the check-in comment to be specified, and following each one up with an amend seems wasteful. Automatically linking branch and tag names to like-named wiki pages doesn't seem like too major a change. But creating a space to provide a short description (akin to a check-in comment) of branches and tags could require a new type of control artifact. Or it could require that the wiki page be specially formatted, e.g. the first paragraph is taken to be the description, which is probably a better idea anyway so it can all be edited in the same interface. Any thoughts? -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Subversion revision tagging
Subversion revision tagging works fine but has the drawback of cluttering the tag list. The Subversion repository I'm working with has over 10K revisions, so that means 10K tags dumped in the tag list, which I would have preferred to keep clear for activity and release labels and the like. That's a lot of noise, and it makes the tags page take a long time to load. Perhaps filtering would be of use. In the site configuration, I could make a couple preset filters and put them in the navigation bar instead of the default Tags link. Thoughts? -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Subversion incremental delta import
Is the Subversion import code supposed to work with incremental delta input? I find it crashes right away. My understanding is it looks in the temporary xfiles table to get the uuid (therefore rid) of existing files (on a given branch), then gets the blob against which the delta is to be applied, then runs the delta to get the new blob. The crash is due to the source blob being empty, yet the delta code assumes otherwise. The source blob is empty because the rid came up zero, i.e. the default value when performing the aforementioned query. gdb lets me make queries into the temporary tables by using the p command to call db_int() or whatever, which is pretty dang cool. It didn't take long to see that xfiles is empty. To fix, xfiles, xbranches, and xrevisions should be initially populated with the contents of the repository so incremental imports build off the result of previous imports. For xrevisions to work, revision tagging must have been enabled in the previous imports, so even the first import must have been treated as an incremental import. I don't see why this wouldn't be doable. Before I dive in, I figured I'd post about it and see if anyone has any comments. -- Andy Goth | signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Automatic Ticket-commit tagging
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? 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. 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. On May 20, 2016, at 8:14 AM, Ron W wrote: > On Fri, May 20, 2016 at 2:21 AM, Steve Schow wrote: > Hmm, very interesting idea about using the EDITOR feature to run a > pre-script…i will have to ponder that…possibly an alternative to using an > actual wrapper script…. > > Sounds like server side TH1 probably won’t do it. > > throwing a table into the checkout DB would be easy enough to do…can use > sqlite directly for that. Its just a convenient place to put it. I’d also > interact with the repo’s ticket table to look for tickets that are “working” > status, etc. I was also thinking of adding a column to the ticket table in > the repo and then putting something there to indicate its the one I’m working > on…in which case I was thinking maybe TH1 could somehow pick it up…but it > sounds like the commit operation doesn’t get to the TH1 to do some action for > adding the ticket uid to its comment? > > Fossil has "post commit" hooks for file commits and ticket updates that run > TH1 scripts configured by the Admin/Transfers page in the Fossil web UI. > > While you might be able to change the various tables in the SQL database, > creating a "control artifact" to insert in the artifact table will also be > required. Other than the artifact table, the DB tables are caches of meta > data from the artifacts. > > In theory, a field like "working on" could live only in the ticket table, but > could be cleared by other updates to the same ticket. > > However, to insert the ticket ID into a ticket comment will require creating > a "control artifact" to contain the modified comment (see > http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) > > Alternately, you can edit the TH1 in the Edit Ticket UI page to support your > "working on this ticket right now" field. Then create a Ticket Report that > reports the currently "working on" tickets (if more than one ticket is > reported, you forgot to make the ticket as not "working on"). Then your > wrapper could use "fossil ticket show workReport" to get ID of "working on" > ticket and insert that ID in the commit comment. > > ___ > 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
Re: [fossil-users] Automatic Ticket-commit tagging
On Fri, May 20, 2016 at 2:21 AM, Steve Schow wrote: > Hmm, very interesting idea about using the EDITOR feature to run a > pre-script…i will have to ponder that…possibly an alternative to using an > actual wrapper script…. > > Sounds like server side TH1 probably won’t do it. > > throwing a table into the checkout DB would be easy enough to do…can use > sqlite directly for that. Its just a convenient place to put it. I’d also > interact with the repo’s ticket table to look for tickets that are > “working” status, etc. I was also thinking of adding a column to the > ticket table in the repo and then putting something there to indicate its > the one I’m working on…in which case I was thinking maybe TH1 could somehow > pick it up…but it sounds like the commit operation doesn’t get to the TH1 > to do some action for adding the ticket uid to its comment? > Fossil has "post commit" hooks for file commits and ticket updates that run TH1 scripts configured by the Admin/Transfers page in the Fossil web UI. While you might be able to change the various tables in the SQL database, creating a "control artifact" to insert in the artifact table will also be required. Other than the artifact table, the DB tables are caches of meta data from the artifacts. In theory, a field like "working on" could live only in the ticket table, but could be cleared by other updates to the same ticket. However, to insert the ticket ID into a ticket comment will require creating a "control artifact" to contain the modified comment (see http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) Alternately, you can edit the TH1 in the Edit Ticket UI page to support your "working on this ticket right now" field. Then create a Ticket Report that reports the currently "working on" tickets (if more than one ticket is reported, you forgot to make the ticket as not "working on"). Then your wrapper could use "fossil ticket show workReport" to get ID of "working on" ticket and insert that ID in the commit comment. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
