1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
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]]
|