In poking around at the svn backend I found that the svn post-commit hook calls to svn update fail regularly with an error code of 256. Apparently during the post-commit hook can't update because the working copy is locked from the commit. Since the post-commit hook doesn't send errors anywhere and svn update runs with --quiet anyhow, this error isn't usually visible, but on my system:
ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ svn commit -m "Blah.."
Sending index.mdwn
Transmitting file data .
Committed revision 3.
#verifying output was created
ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ less ../dest/index.html
ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ svn info
Path: .
URL: file:///home/ethan/tests/webtemplates/ikiwiki3/svn/trunk
Repository Root: file:///home/ethan/tests/webtemplates/ikiwiki3/svn
Repository UUID: f42bb0d6-3c1e-0410-b2d4-aeaad48dd6c4
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: ethan
Last Changed Rev: 2
Last Changed Date: 2006-09-24 21:15:55 -0400 (Sun, 24 Sep 2006)
A sample error message (obtained through file redirection) is:
svn: Working copy '.' locked
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
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 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. 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