On Tue, Sep 2, 2014 at 8:02 PM, Ron W <ronw.m...@gmail.com> wrote: > As I understand it, Fossil is intentionally designed around the feature > set provided by SQLite. Therefore, to support DB back-ends other than > SQLite would not just require rewriting SQL queries, but significant > re-working of Fossil's C implementation. >
Right. sqlite does a surprising amount of the work for us, and having its author write most of the Fossil queries gives us a distinct advantage so long as we use sqlite ;). We also have a huge advantage in the tight coupling of sqlite, in that we know that any serious issues in sqlite get fixed immediately ;), instead of having to wait on the next system update to get the latest Postgres/MySQL/whatever. Certainly, a huge scale DVCS like Fossil would be a good thing. A key > question for a potential project team will be: Once you separate out the DB > back-end, where do you draw the line? > i had to consider some of these points when starting libfossil. One of the ideas i _idly_ tinkered with, in terms of API structure, but never seriously considered, was non-db backends for fossil. It turns out, though, that it's impossible to codify, in advance, all possible data structures which clients might want/need. So.... the db API has to be exposed to the client so that they can define their own data structures (in the form of queries). Creating a storage-agnostic API which "works enough like a DB" that fossil could make reasonable use of it would be a years-long project in and of itself. > As for Fossil itself, it probably scales better than most people think. > Part of the problem is perception. > Guilty as charged. Can't give you concrete reason, though. Maybe it's my inherent pessimism (which possibly has its roots in me enjoying the surprise of, "oh, it CAN be done!"). I know many people who are more comfortable with "large scale" systems like > Perforce, because they are used to working in large organizations. And I > know that some of those do/did work on large software teams. The rest are > like me: The overall "software team" is large, but for any given project, > the number of software members is usually 2, sometimes 1 or 3, rarely more > than that. The "high ceremony" system we are supposed to be using is not > helpful to us. > +1 -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
