On 9/29/15, Stephen Chrzanowski <pontiac76 at gmail.com> wrote: > I did use the UI. It temporarily confused me with the looks until I > realized I was looking at localhost, not the fossil repo.
Did you try "fossil ui" on *your* repository? > > Yeah, I've already investigated the database, but have yet to dig into the > meat of it. On to hour 7 of experience gaining, unless work gets in the > way. ;) > > There are a few things I need to map out in my head to understand the > relational model and get the queries done right. How is the content field > in the blob table work? Is it a compressed string? If you add the "showsql" query parameter to a timeline, it will show you the SQL that is used to generate that timeline. (ex: https://www.fossil-scm.org/fossil/timeline?showsql) So maybe you could get the particular timeline view that you are interested in, then add the "showsql" query parameter, then copy/paste the required SQL into your application. Or at least use that SQL as a starting point. Once you know the artifact ids (the SHA1 hashes) of the stuff you want, it would probably be easier to run "fossil artifact" in a separate process to extract the files. > > It may be documented. I just woke up after an hour and a half of sleep, > and now am at work for 12 hours. So hopefully this stuff will keep me > awake. heh > > On Tue, Sep 29, 2015 at 1:07 PM, Richard Hipp <drh at sqlite.org> wrote: > >> On 9/29/15, Stephen Chrzanowski <pontiac76 at gmail.com> wrote: >> > Long story story short, "fuel" didn't do what I wanted, so it got >> > scrapped. It wouldn't show me a history of what happened to a file >> > (Not >> > even a diff), and it wouldn't show me the contents of the desired file >> > on >> > the fly. I went to the CLI for fossil, found the timeline >> > functionality, >> > and that should do for what I want. I also think I'm using fossil >> > backwards, as it seems to be challenging to go back in time without >> knowing >> > an exact commit ID, and for me, its a bit of a pain. The tags in the >> > fossil DB don't make any sense either. >> >> Have you tried running the "fossil ui" command? >> >> > >> > This where I'll need to write up an app that'll chew through the fossil >> > timeline output... >> >> All of the content is stored in an SQLite database. (The fossil >> repository is just an SQLite database file.) So it might be easier to >> write an app that does a few queries against the database to get the >> information you want. >> >> >> > for whatever files I'm looking for, remember and show the >> > commit IDs based on date/time, extract the commit when I click on an ID >> so >> > I can look at the information I want and verify if it is a version of >> code >> > I want to recompile, run the compiler at my leisure via this new UI, >> verify >> > that the DLL works at a basic level automatically, and then finally >> > automatically commit the DLL to my other SCM (Via command line API) and >> > make sure its commented. With both the console output fossil provides, >> and >> > a GUI to show me the commit IDs and a button to "make it go" when I'm >> > ready, it'll save me countless hours, compared to copy/pasting files >> > and >> > IDs around and manually typing "amalgamation" several times over. If I >> > figure out the fossil database structure well enough, I'll later write >> code >> > to better handle things so I won't have to rely on the CLI output, but >> more >> > importantly, appropriately add tags based on SQLITE_VERSION or >> > SQLITE_VERSION_NUMBER which will make my UI look and function better. >> > >> > Why do I want to do this? >> > >> > Primarily, save time. It'll make life SO much easier when I can yank >> out a >> > pre-compiled DLL marked with a VERY obvious revision number in my SCM >> > and >> > then see what the difference is in my applications. If necessary, I >> > can >> > then go to the amalgamation source code to see if I'm a bonehead or if >> > there really is a problem. >> > >> > With writing this new UI, I'll spend a significant chunk of a day or >> > two >> to >> > save me the frustration of finding older releases, then [extracting, >> > compiling, testing and then committing] each version manually. If >> > fossil >> > can get updates when I want it to on demand, and my app can keep track >> > of >> > where things left off when I last looked at it, I can EASILY keep my >> > self-compiled amalgamation DLLs up to date with a click of two or three >> > mouse buttons. Since all the code is within the fossil DB, even doing >> > a >> > diff between two commit revisions will be a snap, since it throws it >> into a >> > web browser. >> > >> > The *BIG* bonus is that I can now get rid of the 300+meg of zip files >> I've >> > been collecting over this past year. :] (Also, I'll be able to get rid >> of >> > the actual amalgamation source code revision files sitting in my SCM, >> > and >> > not worry about using Bloodshed IDE) >> > >> > >> > On Tue, Sep 29, 2015 at 9:24 AM, Richard Hipp <drh at sqlite.org> wrote: >> > >> >> On 9/29/15, Stephen Chrzanowski <pontiac76 at gmail.com> wrote: >> >> > Thanks, it does. >> >> > >> >> > I'm working under the Win7/64 environment doing the builds using the >> >> > C++ >> >> > Builder from Bloodshed, but I do speak Linux, so I can follow along >> >> > with >> >> > what you're saying here. >> >> >> >> Plain old Fossil is cross-platform. You can download precompiled >> >> binaries for Windows from the website. It is a command-line tool, >> >> though, so you'll need to run it from a command-line shell. >> >> >> >> My view: GUIs are fine for computer *users* but if you want to be a >> >> programmer/developer, you need to be very comfortable using the >> >> command-line. >> >> >> >> Fuel is a third-party GUI tool for Fossil (if I'm not badly mistaken). >> >> If you find it helpful in your daily work, then by all means use it. >> >> But you *still* need to be comfortable using the command-line. >> >> >> > _______________________________________________ >> > sqlite-users mailing list >> > sqlite-users at mailinglists.sqlite.org >> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > >> >> >> -- >> D. Richard Hipp >> drh at sqlite.org >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp drh at sqlite.org
