On Mon, Jun 18, 2018 at 4:43 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Sun, Jun 17, 2018 at 11:07 PM Sam Putman <atmanis...@gmail.com> wrote: > >> About those objects... >> >> What your docs call fossil(1) is written in plain C. Or rather C, Tcl, >> SQL and TH1, if you prefer. >> In any case, not C++. >> > > liubfossil is 100% C89 except that it requires "long long" because sqlite3 > requires it. long long is not strictly C89 but all compilers supports it. > The C++ code in the tree is simply optional high-level wrappers, intended > primarily to allow me to "exercise" the core API, to make sure that it > would be useful in other contexts. > > Oh that's good news. A C++ wrapper is even a useful template for FFI bindings. > I'm still pretty convinced the work on libfossil won't go to waste. >> > >> The excellent documentation alone has advanced my understanding >> considerably. >> > > :) > > >> What might make sense is a sort of 'parallel construction'. Nice thing >> about a revision control >> system, it's got all the revisions. >> >> So to write a clean C libfossil, we can start with the first commit and >> follow the breadcrumbs. >> > > The only "problem" with that (for a given definition of "problem") is that > i'm rather chaotic in terms of how i work on code: there's little rhyme or > reason, nor any specific ordering to commits or (for the most part) > features. You won't find any reasonable order to the timeline. The > implementation required, of course, certain features before others, though, > so... there is that. > > It's never fun to take a forensic approach to a codebase. This was all predicated on some references to a Context object, both in the thread and the docs. A Capitalized pure-C struct being referred to as an object is not unheard of! But it did lead me down the wrong path. > I don't think it's strongly tied to the patch-centric model, it's a >> (relatively) simple matter of >> representing possible outcomes as distinct states. There might be some >> potentially >> exponential bad behavior, we are talking about permutations after all. >> > > It might even be feasible to store each such variation in the 'stash' > table (llibfossil never got far enough to implement the 'stash' or 'undo' > parts, as both depend on the merge process, which was the final "big/scary" > hurdle left to port). > > Looking like all I've got is a small chicken-and-egg problem. Needing to port a few more modules over is a-ok. Trouble is the repos I want to work with are c. 2018 (or ported in 2018 from older git), so they'd be using the new hash. I could start linking in libfossil and poke around an older repository, but that breaks the feedback loop. Big difference between playing around with a library and dogfooding it. I got the sense from the docs that the hash is using the SQLite style versioned API, so it follows that the old hash code is sitting where it needs to. Does this amount to following the style of that file for another similar file in fossil(1)? That's a bite small enough I might be able to chew it.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
