X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/cddb39cbf5d385273645f62f15bdf29b7607aac2..aed4e03b0c850d48722d5f72cbf7bd6a2a052a12:/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn

diff --git a/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn b/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn
index 69af04fe9..2fe97366b 100644
--- a/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn
+++ b/doc/forum/recentchanges_dir_should_be_under_control_of_RCS__63__.mdwn
@@ -31,3 +31,75 @@ 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... :D
+>> 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ł|ptecza]]
+
+>>> 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 [[tips/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ł|ptecza]]