X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/a0f714b20a0ac86b083097c470f4cb982427f707..623c7e17989f53ef049f12639950d2c50c9edd4f:/doc/bugs/svn_fails_to_update.mdwn?ds=inline

diff --git a/doc/bugs/svn_fails_to_update.mdwn b/doc/bugs/svn_fails_to_update.mdwn
index eebace453..6ed839cf6 100644
--- a/doc/bugs/svn_fails_to_update.mdwn
+++ b/doc/bugs/svn_fails_to_update.mdwn
@@ -47,4 +47,43 @@ but *does* happen when committing from the web.
 >> 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
\ No newline at end of file
+>> 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
+
+Hmm, turns out that isn't the case! svn's prepedit function calls svn info 
+which gets the "right" information even when the WC isn't current. I am 
+having problems merging but that probably has nothing to do with this bug. 
+[This patch](http://ikidev.betacantrips.com/patches/update.patch) calls
+rcs_update after commit in CGI.pm, it might be a good idea anyhow. --Ethan
+
+> Ok, I follow you. I am unsure whether this problem effects other rcses
+> besides svn. Depends on how they handle locking, etc. But calling
+> rcs_update will always be safe, so I'll do that. [[bugs/done]]
+> 
+> That still leaves the issue that it calls svn update in the post-commit
+> hook when it's locked and fails with that error message. Granted svn does
+> throw that away by default, but it's still ugly and wasteful. But
+> checking for a lock first is even uglier (and racey) and more wasteful,
+> so I don't see a fix.. --[[Joey]]