Warren Young: > Quantify “a lot.”
I have some rarely committed-to but frequently web-accessed repositories (with login), and I see daily backups of the modified repository database, even though I'm sure I haven't committed anything. It's like "hey, what's going on there with my babies?" everytime, but I need to get used to it. > I’d find out why the DB client is dying early and fix that, so that > the WAL ends up being deleted entirely upon a clean DB shutdown. I think I found it: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html There's a call to fossil_exit() from within a db_step()...db_finalize() block, and calling fossil_exit() only after db_finalize() fixed it. There's been some changes to fossil_exit() in the meantime, I'll check these, and report back here. > I find it odd that some people get so itchy over DB concurrency and > such with Fossil when highly active projects might have 40 or so > commits per day. I'm not worried by this. Stephan just wondered if a shared cookie database may be prone to locks contention, if I got him right. I'd assume the main bottleneck to be high-frequency, read-only, no-login web access (for a renowned project), in which case the cookie database doesn't even need to be attached, and not the frequency of commits. --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
