Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
Conflicts: doc/post-commit/discussion.mdwnmaster
Joey Hess
commit
f328810017
|
|
@ -37,10 +37,6 @@ This element is poorly supported by browsers. As a workaround, `style.css` needs
|
|||
|
||||
Internet Explorer will display it as a block, though you can't seem to be able to further control the style.
|
||||
|
||||
# Validator complains about no h1-h6 in header
|
||||
|
||||
* [#509](http://bugzilla.validator.nu/show_bug.cgi?id=509)
|
||||
|
||||
## Time element
|
||||
|
||||
The [time element](http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element) ideally needs the datatime= attribute set by a template variable with what [HTML5 defines as a valid datetime string](http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#valid-global-date-and-time-string).
|
||||
|
|
|
|||
|
|
@ -65,6 +65,13 @@ The next/previous links are themselves implemented by
|
|||
photo, using a special template (by default `albumnext.tmpl`
|
||||
or `albumprev.tmpl`), in `archive`/`quick` mode.
|
||||
|
||||
> With hindsight, using an inline here is wrong - I should just
|
||||
> run hooks and fill in the template within the album plugin.
|
||||
> inline has some specialized functionality that's overkill
|
||||
> here, and its delayed HTML substitution breaks the ability
|
||||
> to have previous/up/next links both above and below the
|
||||
> photo, for instance. --[[smcv]]
|
||||
|
||||
## Writing the album
|
||||
|
||||
The album contains one `\[[!album]]` directive. It may also
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
[[!template id=plugin name=cvs core=0 author="[[schmonz]]"]]
|
||||
|
||||
This plugin allows ikiwiki to use [[!wikipedia desc="CVS" Concurrent Versions System]] as an [[rcs]].
|
||||
|
||||
* Diffs are against [[3.14159|news/version_3.14159]]. `cvs.pm` started life as a copy of `svn.pm`.
|
||||
* `IkiWiki.pm:wiki_file_prune_regexps` avoids copying CVS metadata into `$DESTDIR`.
|
||||
* [[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 <directory>` from being seen by ikiwiki's [[post-commit]] hook,
|
||||
* configures the wrapper itself as a post-commit hook in `CVSROOT/loginfo`.
|
||||
* [`cvsps`](http://www.cobite.com/cvsps/) is required (`rcs_recentchanges()` and `rcs_diff()` need it to work).
|
||||
* 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 might be possible to solve this problem with scripts like `commit_prep` and `log_accum` from CVS contrib.
|
||||
* Due to the name of CVS's metadata directories, it's impossible to create `.../CVS/foo.mdwn`. On case-insensitive filesystems it's also impossible to create `.../cvs/foo.mdwn`.
|
||||
* No testing or special-casing has been done with [[attachments|plugins/attachment]], but they'll probably need `cvs add -kb`.
|
||||
|
||||
Having a `$HOME/.cvsrc` isn't necessary. Sure does make using CVS more livable, though. Here's a good general-purpose one:
|
||||
|
||||
cvs -q
|
||||
checkout -P
|
||||
update -dP
|
||||
diff -u
|
||||
rdiff -u
|
||||
|
||||
Not knowing how the tests get set up, I blindly attempted to add subversion-like tests to `t/file_pruned.t`. They fail. But the plugin definitely works. :-)
|
||||
|
||||
### Code
|
||||
* [`cvs.pm`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs.pm)
|
||||
* [`cvs-IkiWiki.pm.diff`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-IkiWiki.pm.diff)
|
||||
* [`cvs-ikiwiki-makerepo.diff`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-ikiwiki-makerepo.diff)
|
||||
* [`cvs-t-file_pruned.t.diff`](http://www.netbsd.org/~schmonz/ikiwiki-cvs/cvs-t-file_pruned.t.diff)
|
||||
|
|
@ -13,6 +13,17 @@ This plugin can benefit from
|
|||
[[another_of_my_branches|todo/inline_plugin:_specifying_ordered_page_names]]
|
||||
but does not require it.
|
||||
|
||||
Bugs:
|
||||
|
||||
* \[[!inline pages="..." trail=yes]] currently tries to work out
|
||||
what pages are in the trail, and their order, at scan time. That
|
||||
won't work, because matching a pagespec at scan time is
|
||||
unreliable - pages we want might not have been scanned yet! I
|
||||
haven't worked out a solution for this. I think
|
||||
\[[!inline pagenames="..." trail=yes]]
|
||||
([[patch_required|todo/inline_plugin:_specifying_ordered_page_names]])
|
||||
would be safe, though.
|
||||
|
||||
----
|
||||
|
||||
[[!template id=plugin name=trail author="[[Simon_McVittie|smcv]]"]]
|
||||
|
|
|
|||
|
|
@ -73,12 +73,30 @@ proper order. (cvs add isn't recursive, sadly.)
|
|||
|
||||
Can you offer an educated guess what's going wrong here? --[[Schmonz]]
|
||||
|
||||
> Got `rcs_recentchanges` working, believe it or not, thanks to
|
||||
> [cvsps](http://www.cobite.com/cvsps/). If I can figure out this
|
||||
> interaction between the post-commit hook and `cvs add` on directories,
|
||||
> the CVS plugin is mostly done. Could it be a locking issue? Where should
|
||||
> I be looking? Any suggestions appreciated. --[[Schmonz]]
|
||||
> Got `rcs_recentchanges` working, believe it or not, thanks to [cvsps](http://www.cobite.com/cvsps/). If I can figure out this interaction between the post-commit hook and `cvs add` on directories, the CVS plugin is mostly done. Could it be a locking issue? Where should I be looking? Any suggestions appreciated. --[[Schmonz]]
|
||||
|
||||
>> Okay, it is definitely a locking issue. First, on the conjecture that
|
||||
>> `cvs add <directory>` was triggering the post-commit hook and confusing
|
||||
>> ikiwiki, I wrapped the ikiwiki post-commit binary with a shell script
|
||||
>> that exited 0 if the triggering file was a directory. The first half of
|
||||
>> the conjecture was correct -- my wrapper got triggered -- but the web
|
||||
>> add of `one/two/three.mdwn` (where `one` and `two` weren't existing
|
||||
>> CVS-controlled dirs) remained hung as before. There were two ikiwiki
|
||||
>> processes running. On a whim, I killed the one with the higher PID; `cvs
|
||||
>> add one` immediately completed successfully, then back to a hang and two
|
||||
>> ikiwiki processes. I killed the newer one again and then `cvs add
|
||||
>> one/two` and `cvs add one/two/three.mdwn` completed and the web add was
|
||||
>> successful. --[[Schmonz]]
|
||||
|
||||
>>> Aaaaaand I was wrong about the second half of the conjecture being
|
||||
>>> wrong. The wrapper script wasn't correctly identifying directories;
|
||||
>>> with that fixed, everything works. I've created a
|
||||
>>> [[plugins/contrib/cvs]] plugin page. Thanks for listening. :-)
|
||||
>>> --[[Schmonz]]
|
||||
|
||||
>> Here is a comment I committed to my laptop from Madrid Airport before
|
||||
>> your most recent updates, in case it's still useful:
|
||||
>>
|
||||
>> Locking certianly seems likely to be a problem. ikiwiki calls `rcs_add`
|
||||
>> *before* disabling the post-commit plugin, since all over VCS allow
|
||||
>> adding something in a staged manner. You can see this in, for example,
|
||||
|
|
@ -97,3 +115,4 @@ Can you offer an educated guess what's going wrong here? --[[Schmonz]]
|
|||
>> especially since ikiwiki always commits after an add, in the same
|
||||
>> process, so you could just use a temporary list of things to add.
|
||||
>> --[[Joey]]
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue