On Tue, Sep 2, 2014 at 4:18 PM, <sky5w...@gmail.com> wrote: > My reservation being scalability of large repo support. While I am > unaffected, those professionals charged with release and maintenance of > large code bases look past Fossil and its SQLite core. > Questions: > Will Fossil ever seek to address very large source control? >
Fossil's main target is sqlite (it's a cyclic relationship), and in my humble (but quite fallible) opinion that project won't ever need "very large" source control. Steps have been taken to improve scalability for the benefit large repos, e.g. TCL and pkgsrc(?), but by "very large source control" i envision something akin to git's octopus model, reaching fractally out into the universe, and i don't personally see fossil ever scaling/needing to scale much in that direction. Would it be interesting? Sure, but i suspect it would be seen as quite out of scope for the core project. Can Fossil offer 2 solutions? SQLite based and PostgreSQL(insert big RDB > here)? > In principle, fossil could be implemented in any storage, but in practice a _lot_ of the hard work is done by sqlite, and a port would be painful. That said, both fossil and libfossil abstract most db access behind another layer more suited to fossil, so swapping (e.g.) sqlite3 with sqlite4, 5, or 6 should be relatively painless. (Richard had it running (or compiling) in v4 experimentally at some point, IIRC.) -- ----- 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
