ikiwiki/doc/forum/recentchanges_dir_should_be...

50 lines
2.1 KiB
Plaintext
Raw Normal View History

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
2010-07-05 20:16:36 +02:00
> 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]]