On Sun, Jun 17, 2018 at 4:50 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Sat, Jun 16, 2018 at 11:44 PM Sam Putman <atmanis...@gmail.com> wrote: > >> >> An incremental refactoring of this into something more modular would >> be a boon to maintenance and testing. Seems like a sleeping dog we can >> let lie for now. >> > > That's actually the easy part. The real effort comes in with error > checking and handling, especially in cases where an error may (in a > library) propagated from 3+ levels deep. The app will just exit() at that > point, so no thought has gone (nor needed to go) into error handling or > propagation (because there is no propagation - all errors are "immediate"). > Not only does the propagation at the error-triggering point need to be > decided upon, but how it will propagate arbitrarily far up the call stack. > In the end, libfossil went with a hybrid approach of returning non-0 (from > a well-defined enum of result codes) and the context object holds an Error > object which may (or may not, depending on context) hold more details about > the error. > > 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++. We have fairly strict requirements for the languages we include in our own runtime, because we intend to parse both the syntax and the static semantics of the languages we use. That makes C++ a non starter, as I would imagine it is for including a libfossil as the core of fossil(1). Even for my own needs, the C89-99 family hits the sweet spot; I'm tolerant of ANSIsms in old code but try not to emit them personally. Given that, I'll skip ahead a bit: > > >> >> I concur with Warren that the effort of a libfossil is best justified if >> it becomes the core of fossil proper. >> > > Absolutely 100%, but it's essentially impossible to back-port it into > fossil proper without some massive upheaval. Since fossil lies at the heart > of the sqlite project, there's not (in my somewhat conservatively cautious > view) much room for such severe upheaval. A 3rd-party implementation is > interesting in and of itself, but it would also potentially be a point of > contention, as you say... > 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. > > Tasks like isolating those core intricate algorithms into well-documented >> modules, where >> errors and edge cases are handled where they occur, this can really pay >> off. >> > > That's all in libfossil. > > >> Merging and patch theory are >> areas where real conceptual leaps are still happening. >> > > libfossil has all of fossil's diff algorithms but i don't think i ever > ported the full merge support (it can apply deltas but i don't recall > porting the type of merging decisions which are made during, e.g., a > checkout). Speaking of merging: that's often an interactive process, and > interactivity is difficult to define in a UI-ignorant library. > > This is a legitimately hard problem. Pijul's approach of having a conflict object instead of spraying the merge conflict all over the source file has potential. 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. I'm way ahead of myself there; this is just to say that we can most likely do better than pushing a diff into the source code, while still providing a library API. > The one area of fossil I've done enough reading into to feel comfortable >> in my understanding is the >> file format itself. There's an edge to the documentation and I'm kinda >> peering over that edge slightly. >> > > The "artifact format" documentation is really Fossil's heart. All of the > other parts are implementation details for supporting that. Nonetheless, > any port will certainly want to take advantage of as many of those details > as possible (much of fossil's "heavy lifting" is done with sqlite, and > reimplementing many of those pieces without sqlite would be a massive > undertaking). > SQLite is a core library for bridgetools. I took to heart the "SQLite as alternative to fopen()" slogan, one of the best architectural decisions I've made. That's why we're using fossil as our DVCS, no matter what happens with this libfossil proposal. We are / will be using SQLite for dependency management, bundling, and application file formats already, and even if we have to shell out to fossil(1) we're ahead of the game using a compatible format for our repos. But those intricate algorithms for deduplication, hash chaining, and merging, those would come in handy across the board. A bit about drift: it's a natural outcome of parallel codebases, even with something like a common standard. Without that, it's guaranteed, unless one of the forks doesn't get used.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
