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.
This where I'll need to write up an app that'll chew through the fossil timeline output 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. >
