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]]