From af29201c3ce1099fbc3f8e6986d098fac6cef249 Mon Sep 17 00:00:00 2001 From: "http://schmonz.livejournal.com/" Date: Sun, 9 Aug 2009 22:09:42 -0400 Subject: the post-commit wrapper wrapper also avoids cvs deadlock --- doc/plugins/contrib/cvs.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/plugins') diff --git a/doc/plugins/contrib/cvs.mdwn b/doc/plugins/contrib/cvs.mdwn index db9cde98b..f466b9399 100644 --- a/doc/plugins/contrib/cvs.mdwn +++ b/doc/plugins/contrib/cvs.mdwn @@ -25,9 +25,9 @@ Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn * [[ikiwiki-makerepo]]: * creates a repository, * imports `$SRCDIR` into top-level module `ikiwiki` (vendor tag IKIWIKI, release tag PRE_CVS), - * creates a small post-commit wrapper to prevent `cvs add ` from being seen by ikiwiki's [[post-commit]] hook, + * creates a small post-commit wrapper to prevent `cvs add ` from being seen by ikiwiki's [[post-commit]] hook (and avoid `cvs` locking against itself), * configures the wrapper itself as a post-commit hook in `CVSROOT/loginfo`. -* 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). +* 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.) -- cgit v1.2.3