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
