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. [[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]]
