summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-02-21 07:51:06 +0000
committerjoey <joey@0fa5a96a-9a0e-0410-b3b2-a0fd24251071>2007-02-21 07:51:06 +0000
commit1a7ebe2006b7a707f2566a6aab8e840d0e5382a5 (patch)
tree827b55be9188928ff24c918198d4abd3d2193df5
parent9d48f4c702cff8ab2621676269dc75535d748bd4 (diff)
cgi needs to always render the wiki even if there's a conflict
-rw-r--r--doc/bugs/locking_fun.mdwn5
1 files changed, 4 insertions, 1 deletions
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).