Hello Joey,

I noticed that my Ikiwiki started to rebuild pages very slowly after my last changes when I upgraded Ikiwiki to version 3.20100623. Now I have the latest release 3.20100704, but it doesn't help me.

I started to debug the problem and I found that I can see a lot of messages like below when I try to rebuild my wiki manually:

svn: '/path/to/ikiwiki/trunk/pages/ostatnie_zmiany' is not a working copy
svn: Can't open file '/path/to/ikiwiki/trunk/pages/ostatnie_zmiany/.svn/entries': No such file or directory
svn log exited 256

"ostatnie_zmiany" is a value of recentchangespage parameter in my ikiwiki.setup file. It is not under control Subversion I use for Ikiwiki:

$ svn status pages/ostatnie_zmiany
?      pages/ostatnie_zmiany

$ ls pages/ostatnie_zmiany/*._change |wc -l
100

recentchangesnum parameter has value 100 for me and I noticed that my Ikiwiki takes a lot of time to parse all ._change files. Finally it doesn't refresh /ostatnie_zmiany.html page.

Do you think I should add ostatnie_zmiany directory under control of my Subversion repo? If it's not necessary, could you please give me any hint to find a reason of problem with my Ikiwiki?

My best regards, Pawel

No, the recentchanges pages are automatically generated and should not themselves be in revision control.

Ikiwiki has recently started automatically enabing --gettime, but it should not do it every time, but only on the initial build of a wiki. It will print "querying svn for file creation and modification times.." when it does this. If it's doing it every time, something is wrong. (Specifically, .ikiwiki/indexdb must be missing somehow.)

The support for svn with --gettime is rather poor. (While with git it is quite fast.) But as it's only supposed to happen on the first build, I haven't tried to speed it up. It would be hard to do it fast with svn. It would be possible to avoid the warning message above, or even skip processing files in directories not checked into svn -- but I'd much rather understand why you are seeing this happen on repeated builds. --Joey

Thanks a lot for your reply! I've just checked my rebuild-pages.sh script and discovered that it contains /usr/bin/ikiwiki --setup ikiwiki.setup --gettime command... The warnings disappeared when I removed --gettime parameter. Sorry for confusing!

I have .ikiwiki/indexdb file here, but I noticed that it has been modified about 1 minute after last Subversion commit:

$ LANG=C svn up
At revision 5951.

$ LANG=C svn log -r 5951
------------------------------------------------------------------------
r5951 | svn | 2010-07-06 09:02:30 +0200 (Tue, 06 Jul 2010) | 1 line

web commit by xahil
------------------------------------------------------------------------

$ LANG=C stat pages/.ikiwiki/indexdb 
  File: `pages/.ikiwiki/indexdb'
  Size: 184520       Blocks: 368        IO Block: 131072 regular file
Device: 2bh/43d  Inode: 1931145     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1005/     svn)   Gid: ( 1005/     svn)
Access: 2010-07-06 12:06:24.000000000 +0200
Modify: 2010-07-06 09:03:38.000000000 +0200
Change: 2010-07-06 09:03:38.000000000 +0200

I believe it's the time I have to wait to see that my wiki page has been rebuilt. Do you have any idea how to find a reason of that delay? --Paweł

Well, I hope that your svn post-commit hook is not running your rebuild-pages.sh. That script rebuilds everything, rather than just refreshing what's been changed.

Using subversion is not asking for speed. Especially if your svn repository is on a remote host. You might try disabling recentchanges and see if that speeds up the refreshes (it will avoid one svn log).

Otherwise, take a look at optimising ikiwiki for some advice on things that can make ikiwiki run slowly. --Joey

Thanks for the hints! I don't understand it, but it seems that refreshing all pages has resolved the problem and now my wiki works well again

No, I use rebuild-pages.sh script only when I want to rebuild my wiki manually, for example when you release new Ikiwiki version then I need to update my templates. Some of them have been translated to Polish by me.

Fortunately my wiki and its Subversion repo are located on the same host. We have a lot of Subversion repos for our projects and I don't want to change only wiki repo for better performance. I'm rather satisfied with its speed. --Paweł