I did use the UI. It temporarily confused me with the looks until I realized I was looking at localhost, not the fossil repo.
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? 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 >
