X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/232abc81539c919281d0dbc6860fd33ad732a810..300e86be13b0242b82d52bfaf87b379447569e23:/doc/bugs/svn_fails_to_update.mdwn

diff --git a/doc/bugs/svn_fails_to_update.mdwn b/doc/bugs/svn_fails_to_update.mdwn
index b10e8189b..fda003a44 100644
--- a/doc/bugs/svn_fails_to_update.mdwn
+++ b/doc/bugs/svn_fails_to_update.mdwn
@@ -31,4 +31,43 @@ A sample error message (obtained through file redirection) is:
     svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
 
 Did I do something stupid again or is this the case on your system too? 
+--Ethan
+
+Additional note: this doesn't happen when performing svn commits from another wc, 
+but *does* happen when committing from the web.
+--Ethan
+
+> Yeah, this makes sense now that you bring it up. Perhaps I should make
+> ikiwiki skip the update when called from the post-commit hook if the repo
+> is locked, although this could mask other problems.. --[[Joey]]
+
+>> I don't think it's (yet) a serious problem, because any commit to the repo
+>> either comes from another WC, in which case, no problem, or it is committed by 
+>> ikiwiki through its own WC, in which case that WC is "the newest". The only problem
+>> is that ikiwiki's rcs information for web commits gets screwed up. I think the
+>> correct fix is to call rcs_update from rcs_commit in svn.pm, if 
+>> the commit succeeds. I'm not sure whether this ought to happen for all RCSes
+>> or just svn. --Ethan
+
+>>> You say that the rcs information for web commits is screwed up .. how? 
+>>> Does this affect something that I'm not seeing? --[[Joey]]
+
+I just meant that when you call ikiwiki.cgi?do=edit, it gets the 
+"current" RCS revision, and uses that in the merges later if there
+are other edits in the meantime. So I guess if you have a file a.mdwn,
+and at revision X it contains the list:
+
+    a
+    b
+    c
+    d
+
+And then one user edits it by removing "c" from web, and 
+then starts editing it again, ikiwiki.cgi will think the edit "started"
+at revision X (although it's really X+1). So if another user edits via
+web in the meantime, the subsequent merge will try to remove "c" again.
+To be honest I don't know what will happen in this case (svn merge fails?
+conflict markers?), but I'm pretty sure it's a problem. Anyhow, I think we 
+should call update manually after commit, I just don't know if this should
+be RCS-specific, or whether it's safe to update after commit on all RCSes.
 --Ethan
\ No newline at end of file