Yes, I did run [fossil ui], which launched a web browser to localhost/ 127.0.0.1.
I didn't know about showsql. That'll absolutely help. On Tue, Sep 29, 2015 at 8:09 PM, Richard Hipp <drh at sqlite.org> wrote: > 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 > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
