did you try "fossil ui"?

> -----Original Message-----
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Stephen Chrzanowski
> Sent: Tuesday, 29 September, 2015 10:58
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Odd download file names
> 
> 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.
> >
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



Reply via email to