3 files changed, 82 insertions, 0 deletions
diff --git a/doc/plugins/contrib/cvs/discussion.mdwn b/doc/plugins/contrib/cvs/discussion.mdwn
index b063a53c2..2de938fb7 100644
--- a/doc/plugins/contrib/cvs/discussion.mdwn
+++ b/doc/plugins/contrib/cvs/discussion.mdwn
@@ -36,6 +36,19 @@ the "cvs add <directory>" call and avoid doing anything in that case?
 >>>> other plugins support could be a problem if another user runs
 >>>> the setuid wrapper and passes those options through. --[[Joey]]
 
+>>>>> I've tried compiling the argument check into the wrapper as
+>>>>> the first thing main() does, and was surprised to find that
+>>>>> this doesn't prevent the `cvs add <dir>` deadlock in a web
+>>>>> commit. I was convinced this'd be a reasonable solution,
+>>>>> especially if conditionalized on the cvs plugin being loaded,
+>>>>> but it doesn't work. And I stuck debug printfs at the beginning
+>>>>> of all the rcs_foo() subs, and whatever `cvs add <dir>` is
+>>>>> doing to ikiwiki isn't visible to my plugin, because none of
+>>>>> those subs are getting called. Nuts. Can you think of anything
+>>>>> else that might solve the problem, or should I go back to
+>>>>> generating a minimal wrapper wrapper that checks for just
+>>>>> this one thing? --[[schmonz]]
+
 > Thing 2 I'm less sure of. (I'd like to see the web UI return
 > immediately on save anyway, to a temporary "rebuilding, please wait
 > if you feel like knowing when it's done" page, but this problem
diff --git a/doc/plugins/contrib/rsync.mdwn b/doc/plugins/contrib/rsync.mdwn
new file mode 100644
index 000000000..71cd63947
--- /dev/null
+++ b/doc/plugins/contrib/rsync.mdwn
@@ -0,0 +1,21 @@
+[[!template id=plugin name=rsync core=0 author="[[schmonz]]"]]
+
+[[!template id=gitbranch branch=schmonz author="[[schmonz]]"]]
+
+This plugin allows ikiwiki to push generated pages to another host
+by running a command such as `rsync`.
+
+### Usage
+7. Enable automated SSH key exchange between ikiwiki and the remote
+   host. [keychain](http://www.gentoo.org/proj/en/keychain/) makes
+   it easy to use a passphrase-protected key for this purpose. It's
+   also a good idea to specify the exact command line to be permitted
+   in the remote host's `$HOME/.ssh/authorized_keys`.
+7. Set `rsync_command` in your setup file. If you're using a
+   passphrase-protected key, then set `rsync_command` to a shell
+   script which reads `keychain`'s current state before calling
+   `rsync`.
+
+### Implementation details
+* The plugin relies on a new "postrefresh" hook called at the very end of
+  `IkiWiki/Render.pm:refresh()`.
diff --git a/doc/plugins/contrib/rsync/discussion.mdwn b/doc/plugins/contrib/rsync/discussion.mdwn
new file mode 100644
index 000000000..20c04af0f
--- /dev/null
+++ b/doc/plugins/contrib/rsync/discussion.mdwn
@@ -0,0 +1,48 @@
+## A use case
+
+Why I needed this plugin: I have two web servers available to me
+for a project. Neither does everything I need, but together they
+do. (This is a bit like the [Amazon S3
+scenario](http://kitenet.net/~joey/blog/entry/running_a_wiki_on_Amazon_S3/).)
+
+Server (1) is a university web server. It provides plentiful space
+and bandwidth, easy authentication for people editing the wiki, and
+a well-known stable URL. The wiki really wants to live here and
+very easily could except that the server doesn't allow arbitrary
+CGIs.
+
+Server (2) is provided by a generous alumnus's paid [[tips/DreamHost]]
+account. Disk and particularly network usage need to be minimized
+because over some threshold it costs him. CGI, etc. are available.
+
+My plan was to host the wiki on server (1) by taking advantage of
+server (2) to store the repository, source checkout, and generated
+pages, to host the repository browser, and to handle ikiwiki's CGI
+operations. In order for this to work, web edits on (2) would need
+to automatically push any changed pages to (1).
+
+As a proof of concept, I added an rsync post-commit hook after
+ikiwiki's usual. It worked, just not for web edits, which is how
+the wiki will be used. So I wrote this plugin to finish the job.
+The wiki now lives on (1), and clicking "edit" just works. --[[schmonz]]
+
+> Just out of interest, why use `rsync` and not `git push`.  i.e. a
+> different setup to solve the same problem would be to run a
+> normal ikiwiki setup on the universities server with its git
+> repository available over ssh (same security setup your using
+> for rsync should work for git over ssh).  On the cgi-capable server,
+> when it would rsync, make it git push.  It would seem that git
+> has enough information that it should be able to be more
+> network efficient.  It also means that corruption at one end
+> wouldn't be propagated to the other end. -- [[Will]]
+
+>> Hey, that's a nice solution. (The site was in svn to begin with,
+>> but it's in git now.) One advantage of my approach in this particular
+>> case: server (1) doesn't have `git` installed, but does have `rsync`,
+>> so (1)'s environment can remain completely untweaked other than the
+>> SSH arrangement. I kind of like that all the sysadmin effort is
+>> contained on one host.
+>>
+>> This plugin is definitely still useful for projects not able to use
+>> a DVCS (of which I've got at least one other), and possibly for
+>> other uses not yet imagined. ;-) --[[schmonz]]