(no commit message)
[ikiwiki] / doc / bugs / svn_fails_to_update.mdwn
1 In poking around at the svn backend I found that the svn post-commit 
2 hook calls to svn update fail regularly with an error code of 256. 
3 Apparently during the post-commit hook can't update because the 
4 working copy is locked from the commit. Since the post-commit hook doesn't send
5 errors anywhere and svn update runs with --quiet anyhow, this error
6 isn't usually visible, but on my system:
7
8     ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ svn commit -m "Blah.."
9     Sending        index.mdwn
10     Transmitting file data .
11     Committed revision 3.
12
13     #verifying output was created
14     ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ less ../dest/index.html 
15
16     ethan@sundance:~/tests/webtemplates/ikiwiki3/wc$ svn info
17     Path: .
18     URL: file:///home/ethan/tests/webtemplates/ikiwiki3/svn/trunk
19     Repository Root: file:///home/ethan/tests/webtemplates/ikiwiki3/svn
20     Repository UUID: f42bb0d6-3c1e-0410-b2d4-aeaad48dd6c4
21     Revision: 2
22     Node Kind: directory
23     Schedule: normal
24     Last Changed Author: ethan
25     Last Changed Rev: 2
26     Last Changed Date: 2006-09-24 21:15:55 -0400 (Sun, 24 Sep 2006)
27
28 A sample error message (obtained through file redirection) is:
29
30     svn: Working copy '.' locked
31     svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
32
33 Did I do something stupid again or is this the case on your system too? 
34 --Ethan
35
36 Additional note: this doesn't happen when performing svn commits from another wc, 
37 but *does* happen when committing from the web.
38 --Ethan
39
40 > Yeah, this makes sense now that you bring it up. Perhaps I should make
41 > ikiwiki skip the update when called from the post-commit hook if the repo
42 > is locked, although this could mask other problems.. --[[Joey]]
43
44 >> I don't think it's (yet) a serious problem, because any commit to the repo
45 >> either comes from another WC, in which case, no problem, or it is committed by 
46 >> ikiwiki through its own WC, in which case that WC is "the newest". The only problem
47 >> is that ikiwiki's rcs information for web commits gets screwed up. I think the
48 >> correct fix is to call rcs_update from rcs_commit in svn.pm, if 
49 >> the commit succeeds. I'm not sure whether this ought to happen for all RCSes
50 >> or just svn. --Ethan
51
52 >>> You say that the rcs information for web commits is screwed up .. how? 
53 >>> Does this affect something that I'm not seeing? --[[Joey]]
54
55 I just meant that when you call ikiwiki.cgi?do=edit, it gets the 
56 "current" RCS revision, and uses that in the merges later if there
57 are other edits in the meantime. So I guess if you have a file a.mdwn,
58 and at revision X it contains the list:
59
60     a
61     b
62     c
63     d
64
65 And then one user edits it by removing "c" from web, and 
66 then starts editing it again, ikiwiki.cgi will think the edit "started"
67 at revision X (although it's really X+1). So if another user edits via
68 web in the meantime, the subsequent merge will try to remove "c" again.
69 To be honest I don't know what will happen in this case (svn merge fails?
70 conflict markers?), but I'm pretty sure it's a problem. Anyhow, I think we 
71 should call update manually after commit, I just don't know if this should
72 be RCS-specific, or whether it's safe to update after commit on all RCSes.
73 --Ethan
74
75 Hmm, turns out that isn't the case! svn's prepedit function calls svn info 
76 which gets the "right" information even when the WC isn't current. I am 
77 having problems merging but that probably has nothing to do with this bug. 
78 [This patch](http://ikidev.betacantrips.com/patches/update.patch) calls
79 rcs_update after commit in CGI.pm, it might be a good idea anyhow. --Ethan
80
81 > Ok, I follow you. I am unsure whether this problem effects other rcses
82 > besides svn. Depends on how they handle locking, etc. But calling
83 > rcs_update will always be safe, so I'll do that. [[bugs/done]]
84
85 > That still leaves the issue that it calls svn update in the post-commit
86 > hook when it's locked and fails with that error message. Granted svn does
87 > throw that away by default, but it's still ugly and wasteful. But
88 > checking for a lock first is even uglier (and racey) and more wasteful,
89 > so I don't see a fix.. --[[Joey]]