* Always call rcs_update after a commit during a web edit, to work around

the problem described in bugs/svn_fails_to_update. Thanks to Ethan for the
  analysis and patch.
master
joey 2007-01-28 00:26:55 +00:00
parent 8276eb6311
commit 4ff60ef1c5
3 changed files with 21 additions and 2 deletions

View File

@ -507,6 +507,12 @@ sub cgi_editpage ($$) { #{{{
print $form->render(submit => \@buttons);
return;
}
else {
# Make sure that the repo is up-to-date;
# locking prevents the post-commit hook
# from updating it.
rcs_update();
}
}
else {
require IkiWiki::Render;

5
debian/changelog vendored
View File

@ -11,8 +11,11 @@ ikiwiki (1.41) UNRELEASED; urgency=low
* Improve use of svn merge, by specifying the file to merge, rather than
chdiring to the srcdir (which wasn't right when merging in a subdir).
Thanks Ethan.
* Always call rcs_update after a commit during a web edit, to work around
the problem described in bugs/svn_fails_to_update. Thanks to Ethan for the
analysis and patch.
-- Joey Hess <joeyh@debian.org> Sat, 27 Jan 2007 19:01:27 -0500
-- Joey Hess <joeyh@debian.org> Sat, 27 Jan 2007 19:18:27 -0500
ikiwiki (1.40) unstable; urgency=low

View File

@ -76,4 +76,14 @@ 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
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]]