Stephan Beal <sgb...@googlemail.com> writes: > i don't have any more ideas off-hand, but i've never worked with repos > having anywhere near that many files.
After seeing that Eric's advice to turn checksumming off helps, I wonder if there is something which can be done to make Fossil operate better in this use-case? $du -h financije 789M financije/ while the main file in the repo is 4.6M. The rest of the repo is populate with many files which are often very small (few K) and very short-lived, iow. those are so called *.log files of backup data files which are handy when/if one has to restore some old transactions in case something goes wrong (I had to use it several times), but the point is that, according to docs, "Gnucash will remove them after a configurable amount of time (Preferences/General/"Days to retain log files")." So, the whole repo/project is not Linux kernel in size, but those small file accumulated in the course of time making the size of the whole repo 6G (uncompressed) with very long commit time when checksum checking is on? Let me say that when I was using this repo with Git I never had any performance problem, but it's understandable considering its different storage design and use of GC periodically. Sincerely, Gour -- Thus the wise living entity's pure consciousness becomes covered by his eternal enemy in the form of lust, which is never satisfied and which burns like fire. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
