diff options
| -rw-r--r-- | doc/ikiwiki/directive/inline.mdwn | 2 | ||||
| -rw-r--r-- | doc/plugins/contrib/cvs.mdwn | 13 | ||||
| -rw-r--r-- | doc/plugins/recentchanges.mdwn | 3 | ||||
| -rw-r--r-- | doc/tips/DreamHost/discussion.mdwn | 13 | ||||
| -rw-r--r-- | doc/todo/should_optimise_pagespecs.mdwn | 8 |
5 files changed, 30 insertions, 9 deletions
diff --git a/doc/ikiwiki/directive/inline.mdwn b/doc/ikiwiki/directive/inline.mdwn index 9c55e07c2..99f795972 100644 --- a/doc/ikiwiki/directive/inline.mdwn +++ b/doc/ikiwiki/directive/inline.mdwn @@ -56,7 +56,7 @@ directive. These are the commonly used ones: * `postform` - Set to "yes" to enable a form to post new pages to a blog. * `postformtext` - Set to specify text that is displayed in a postform. -* `rootpage` - Enable the postform, and allows controling where +* `rootpage` - Enables the postform, and allows controling where newly posted pages should go, by specifiying the page that they should be a [[SubPage]] of. diff --git a/doc/plugins/contrib/cvs.mdwn b/doc/plugins/contrib/cvs.mdwn index f466b9399..23e00201f 100644 --- a/doc/plugins/contrib/cvs.mdwn +++ b/doc/plugins/contrib/cvs.mdwn @@ -1,14 +1,11 @@ [[!template id=plugin name=cvs core=0 author="[[schmonz]]"]] +[[!template id=gitbranch branch=schmonz author="[[schmonz]]"]] + This plugin allows ikiwiki to use [[!wikipedia desc="CVS" Concurrent Versions System]] as an [[rcs]]. -### Installation and usage -7. Apply patches to [`IkiWiki.pm`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-IkiWiki.pm.diff) -and [`ikiwiki-makerepo`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-ikiwiki-makerepo.diff). -7. Rebuild and install ikiwiki. +### Usage 7. Install [cvsps](http://www.cobite.com/cvsps/), [[!cpan IPC::Cmd]], [[!cpan String::ShellQuote]], and [cvsweb](http://www.freebsd.org/projects/cvsweb.html) or the like. -7. Download [`cvs.pm`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs.pm) into a suitable `$libdir/IkiWiki/Plugin`. -7. While setting up a wiki [[by hand|setup/byhand]], also specify `--libdir` until you get to the point where you have a setup file. (This ensures the CVS plugin is found and its settings stanza included.) 7. Adjust CVS-related parameters in your setup file. Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn't need it, but you yourself might. Here's a good general-purpose one: @@ -20,7 +17,7 @@ Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn rdiff -u ### Implementation details -* Diffs are against [[3.14159|news/version_3.14159]]. `cvs.pm` started life as a copy of `svn.pm`. +* `cvs.pm` started life as a copy of [[3.14159|news/version_3.14159]]'s `svn.pm`. * `IkiWiki.pm:wiki_file_prune_regexps` avoids copying CVS metadata into `$DESTDIR`. * [[ikiwiki-makerepo]]: * creates a repository, @@ -30,7 +27,7 @@ Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn * CVS multi-directory commits happen separately; the post-commit hook sees only the first directory's changes in time for [[recentchanges|plugins/recentchanges]]. The next run of `ikiwiki --setup` will correctly re-render such a recentchanges entry. It should be possible to solve this problem with NetBSD's `commit_prep` and `log_accum` scripts (see below). ### To do -* Add automated tests. ([Blindly adding svn-like tests to `t/file_pruned.t`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-t-file_pruned.t.diff) doesn't do the trick.) +* Add automated tests. (Blindly adding svn-like tests to `t/file_pruned.t` doesn't do the trick.) * If the argument to `cvs add` smells like a binary file, `cvs add -kb` it (for [[plugins/attachment]] support). * Don't slurp the entire `cvsps` output into memory (!). * Instead of resource-intensively scraping changesets with `cvsps`, have `ikiwiki-makerepo` set up NetBSD-like `log_accum` and `commit_prep` scripts that coalesce and keep records of commits. `cvsps` can be used as a fallback for repositories without such records. diff --git a/doc/plugins/recentchanges.mdwn b/doc/plugins/recentchanges.mdwn index 4ab2cd078..9375296a4 100644 --- a/doc/plugins/recentchanges.mdwn +++ b/doc/plugins/recentchanges.mdwn @@ -24,3 +24,6 @@ Here's an example of how to show only changes that Joey didn't make. \[[!inline pages="internal(recentchanges/change_*) and !author(joey) and !author(http://joey.kitenet.net*)" template=recentchanges show=0]] + +If you want to generate feeds for the RecentChanges page, you have to use +[[`rss`_or_`atom`_in_the_setup_file|/todo/minor adjustment to setup documentation for recentchanges feeds]]. diff --git a/doc/tips/DreamHost/discussion.mdwn b/doc/tips/DreamHost/discussion.mdwn index 74f48938e..258d385ae 100644 --- a/doc/tips/DreamHost/discussion.mdwn +++ b/doc/tips/DreamHost/discussion.mdwn @@ -3,3 +3,16 @@ I managed to install ikiwiki on eggplant farms, with most basic features except I think ikiwiki is more suitable for VPS/dedicated server. Shared hosting doesn't fit. I just (2009/04/27) installed ikiwiki on DreamHost and the CPAN instructions here are unnecessarily complicated. I used "cpan" instead of "perl -MCPAN -e shell" and had no trouble with that portion of the install. --[[schmonz]] + +After tiring of managing things by hand, I've switched to using +pkgsrc as an unprivileged user. This uses a bit more disk for my +own copies of perl, python, etc., but in exchange I can `cd +.../pkgsrc/www/ikiwiki && make install` and everything just works. +Plus I get all the benefits of a package system, like easy uninstalling +and being notified of outdated or insecure software. + +The only catch: sometimes the package dependency tree gets too deep +for DreamHost's user process limit, resulting in build death. I +work around this by resuming the build partway down the tree, then +trying again from whatever I was actually trying to install. +--[[schmonz]] diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 1919e3584..9d2611249 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -120,6 +120,14 @@ separate item, the list can get rather long, and that single add_depends loop has suddenly become O(N^2) to the number of pages, which is something to avoid.. +> I was also thinking about this (I've been playing with some stuff based on the +> `remove-pagespec-merge` branch). A hash, by itself, is not optimal because +> the dependency list holds two things: page names and page specs. The hash would +> work well for the page names, but you'll still need to iterate through the page specs. +> I was thinking of keeping a list and a hash. You use the list for pagespecs +> and the hash for individual page names. To make this work you need to adjust the +> API so it knows which you're adding. -- [[Will]] + Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be marginally faster, probably, and should allow for better optimisation |