On Mon, Oct 24, 2016 at 10:35:46AM -0600, Warren Young wrote: > As far as I can tell, syncing to a remote repository locks the entire > remote repository, making it *worse* than Fossil, not better. (SQLite > concurrency locks only single tables, not the whole database, and then > only for writes, not reads.)
If you use WAL mode, you can have a single writer locking the whole database for the transaction, but pure readers can continue fine. I would have to check how this interacts with the temporary tables needed by the xfer code for pulls, e.g. whether pulls need a write transaction or not. The only scalability issue on the hosting side I really hit more than a couple of times is related to certain Chinese spiders following every link they can and ignoring robots.txt. That's an issue for any version control system though. I can assure you that repository hosting is the smallest issue, even for very large repositories. I have some old presentations still online talking about the NetBSD repository and the fossil conversion, that's likely still one of the biggest fossil repositories around: http://www.sonnenberger.org/archive/presentations/fossil/ http://www.sonnenberger.org/archive/presentations/fossil2/ (content mostly the same, from 2011) Joerg _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
