On 9/2/2014 08:27, Stephan Beal wrote:
On Tue, Sep 2, 2014 at 4:18 PM, <[email protected] <mailto:[email protected]>> wrote: 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.
While I don't think moving to PostgreSQL is the right answer, there are some things about Fossil where it's making SQLite-based assumptions that break down in projects with large repos.
SQLite is a relatively tight code base with little in the way of media files checked into the repo. The SQLite repo is currently 52 megs.
The Fossil repo for the web app I work on is 284 megs, probably in very large part because I check in two copies of most every graphic used in the web app: a high-res multi-layered "working" copy, and a downsampled flattened and optimized PNG version for display. Every time one of these files changes, the whole file has to be copied back into the repo, because you can't diff a PSD or PNG file. (Well, *Fossil* can't.)
Fossil currently wants to do a cryptographically strong checksum on every version of every graphic file I've ever created on every checkin. Consequently, a checkin takes several seconds here.
There was a recent proposal that you should be able to turn that feature of Fossil off, which would help a lot in such cases.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
