This is with regards to the problem described here: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/000060.html
We are seeing on the order of 3-5 of these a year in our heaviest hit repos. While this may seem like no big deal the fact that it is so silent is quite disruptive. The problem is that a developer working intently on a problem may not notice for hours or even days that they are no longer actually working on the main thread of development. We added the fork detection code to the fossil wrapper which helps (we also see forks due to time lag on syncing between remote sites) but it is still a rather annoying problem. My question is can this be solved by wrapping the code that determines that we are at a leaf and the code that does the final commit with a "BEGIN IMMEDIATE;" ... "END;"? This increases the risk of leaving the db in a locked state so having a fossil command to unlock a database would be nice. In this same vein it would be very nice to be able to control the sqlite3 timeout. I'm fairly sure that a longer timeout would give us much better behaviour in our usage model. I have some scripting that can generate the forks and I'm willing to take a stab at making this change but wanted to hear from the list if this solution was worth trying.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
