X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/9d48f4c702cff8ab2621676269dc75535d748bd4..24b83435061f94c6e203ed1b31b114b53ab8b8a3:/doc/bugs/locking_fun.mdwn?ds=inline

diff --git a/doc/bugs/locking_fun.mdwn b/doc/bugs/locking_fun.mdwn
index 6d5f79ce5..64d06917f 100644
--- a/doc/bugs/locking_fun.mdwn
+++ b/doc/bugs/locking_fun.mdwn
@@ -146,7 +146,9 @@ makes the commit hook a NOOP.
   (it may still need to send commit mails)
 * CGI removes wclock, thus re-enabling the commit hook
 * CGI updates the WC (since the commit hook didn't)
-* CGI renders the wiki
+* CGI renders the wiki (always. commits may have came in and not been
+  rendered)
+* CGI checks for conflicts, and if any are found does its normal dance
 
 > It seems like there are two things to be concerned with: RCS commit between
 > disable of hook and CGI commit, or RCS commit between CGI commit and re-enable
@@ -180,6 +182,7 @@ NOOP:
 * svn commit -m "conflict" (this makes a change to repo immediately, then
   runs the post-commit hook, which becomes a NOOP)
 * cgi calls rcs_commit, which fails due to the conflict just introduced
+* cgi renders the wiki
 
 Actually, the only thing that scares me about this apprach a little is that
 we have two locks. The CGI takes them in the order (wikilock, wclock).