90 lines
4.0 KiB
Markdown
90 lines
4.0 KiB
Markdown
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](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]]
|