]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
authorJoey Hess <joey@kitenet.net>
Tue, 28 Dec 2010 17:51:12 +0000 (13:51 -0400)
committerJoey Hess <joey@kitenet.net>
Tue, 28 Dec 2010 17:51:12 +0000 (13:51 -0400)
doc/plugins/contrib/transient.mdwn
doc/todo/autoindex_should_use_add__95__autofile.mdwn
doc/todo/transient_pages.mdwn

index ff2fab610f1607c3916d69a4f9755c82bc016d80..6003196b0cac6aee99dc2fdef8fb77aedb5f25cb 100644 (file)
@@ -1,9 +1,35 @@
+*For discussion and the branch please see [[todo/transient pages]]. If this
+plugin is merged, this page can be renamed to act as its documentation. --[[smcv]]*
+
 [[!template id=plugin name=transient author="[[Simon_McVittie|smcv]]"]]
-[[!template id=gitbranch branch=smcv/ready/transient author="[[Simon_McVittie|smcv]]"]]
 [[!tag type/special-purpose]]
 
-The `transient` plugin is an implementation of [[todo/transient pages]]
-in an underlay. It's mostly useful as something other plugins can depend on;
-[[plugins/contrib/album]] puts photo-album "viewer" pages there,
-and the versions of [[plugins/autoindex]] and [[plugins/tag]] on the
-same branch optionally put their auto-generated pages there.
+The `transient` plugin adds an underlay in `.ikiwiki/transient`, which is
+intended for pages that are automatically created and should not be committed
+to the [[RCS]]. It works in the same way as the [[basewiki]] and the underlays
+set up by the [[plugins/underlay]] plugin, so if a page in the transient
+underlay is edited via the web, the edited version is committed to the RCS
+as usual. Unlike other underlays, if a page in the transient underlay is
+superseded by an edited version in the RCS, the old transient version
+is deleted automatically.
+
+This plugin is mostly useful as something that other plugins can depend on:
+
+* [[plugins/contrib/album]] always writes photo-album "viewer" pages to the
+  transient underlay
+
+Likely future users of this plugin (the appropriate branches need to be
+merged first):
+
+* with a patch (which exists but hasn't yet been tested), [[plugins/aggregate]]
+    always writes aggregated posts into the transient underlay
+* with a patch, [[plugins/autoindex]] can be configured to auto-create missing
+    pages that have a [[ikiwiki/subpage]] or an [[plugins/attachment]], but not
+    commit them, in which case they go in the transient underlay
+* [[plugins/comments]] can be configured to not commit comments: if so, it
+    should probably put them in the transient underlay
+* with a patch, [[plugins/recentchanges]] always writes new changes into the
+    transient underlay
+* with a patch, [[plugins/tag]] can be configured to auto-create missing
+    tag pages but not commit them, in which case they go in the transient
+    underlay
index 353168c4faa414c3c09ae19ea12eb215c30443c3..c073173f3e0db604cd8e6a31989c9efee7b3f4cb 100644 (file)
@@ -15,6 +15,8 @@ quite, entirely unlike". I tried digging through the git history for the
 reasoning behind the autofile and autoindex implementations, but now I'm
 mostly confused.
 
+## autofile
+
 The autofile machinery records a list of every file that has ever been proposed
 as an autofile: for instance, the tag plugin has a list of every tag that
 has ever been named in a \[[!tag]] or \[[!taglink]], even if no file was
@@ -23,11 +25,76 @@ already exist (or whatever) are deferred until after this list has been
 updated, and files in this list are never auto-created again unless the wiki
 is rebuilt.
 
+This avoids re-creating the tag `create-del` in this situation, which is
+the third one that I noted on
+[[todo/auto-create tag pages according to a template]]:
+
+* create tags/create-del manually
+* tag a page as create-del
+* delete tags/create-del
+
+and also avoids re-creating `auto-del` in this similar situation (which I
+think is probably the most important one to get right):
+
+* tag a page as auto-del, which is created automatically
+* delete tags/auto-del
+
+I think both of these are desirable.
+
+However, this infrastructure also results in the tag page not being
+re-created in either of these situations (the first and second that I noted
+on the other page):
+
+* tag a page as auto-del-create-del, which is created automatically
+* delete tags/auto-del-create-del
+* create tags/auto-del-create-del manually
+* delete tags/auto-del-create-del again
+
+or
+
+* create tags/create-del-auto
+* delete tags/create-del-auto
+* tag a page as create-del-auto
+
+I'm less sure that these shouldn't create the tag page: we deleted the
+manually-created version, but that doesn't necessarily mean we don't want
+*something* to exist.
+
+## autoindex
+
 The autoindex machinery records a more complex set. Items are added to the
 set when they are deleted, but would otherwise have been added as an autoindex
 (don't exist, do have children (by which I mean subpages or attachments),
 and are a directory in the srcdir). They're removed if this particular run
 wouldn't have added them as an autoindex (they exist, or don't have children).
 
-Still researching why there's this difference, and whether one or the other
-would be better for all cases...
+Here's what happens in situations mirroring those above.
+
+The "create-del" case still doesn't create the page:
+
+* create create-del manually
+* create create-del/child
+* delete create-del
+* it's added to `%deleted` and not re-created
+
+Neither does the "auto-del" case:
+
+* create auto-del/child, resulting in auto-del being created automatically
+* delete auto-del
+* it's added to `%deleted` and not re-created
+
+However, unlike the generic autofile infrastructure, `autoindex` forgets
+that it shouldn't re-create the deleted page in the latter two situations:
+
+* create auto-del-create-del/child, resulting in auto-del-create-del being
+    created automatically
+* delete auto-del-create-del; it's added to `%deleted` and not re-created
+* create auto-del-create-del manually; it's removed from `%deleted`
+* delete auto-del-create-del again (it's re-created)
+
+and
+
+* create create-del-auto
+* delete create-del-auto; it's not added to `%deleted` because there's no
+    child that would cause it to exist
+* create create-del-auto/child
index 8ead0815c35207e074e7acd42d1ac0598c9541c6..f4cbdfc8b7a9476969b37243c01d237f145cfae8 100644 (file)
@@ -21,8 +21,9 @@ It could also be used for an [[todo/alias_directive]].
 
 --------------------------
 
-[[!template id=gitbranch branch=smcv/transient-only author="[[smcv]]"]]
-[[!template id=gitbranch branch=smcv/transient-recentchanges author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/transient-recentchanges author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/transient-tag author="[[smcv]]"]]
 [[!tag patch]]
 
 I think this branch is now enough to be useful. It adds the following:
@@ -32,11 +33,11 @@ as an underlay. I'm not sure whether this should be a plugin or core, so
 I erred on the side of more plugins; I think it's "on the edge of the core",
 like goto.
 
-Pages with the default extension in the transient underlay are automatically
+Pages in the transient underlay are automatically
 deleted if a page of the same name is created in the srcdir (or an underlay
 closer to the srcdir in stacking order).
 
-With the additional `transient-tag` branch,
+With the additional `ready/transient-tag` branch,
 `tag` enables `transient`, and if `tag_autocreate_commit` is set to 0
 (default 1), autocreated tags are written to the transient underlay.
 There is a regression test.
@@ -44,7 +45,9 @@ There is a regression test.
 With the additional `transient-autoindex` branch,
 `autoindex` uses autofiles. It also enables `transient`, and if
 `autoindex_commit` is set to 0 (default 1), autoindexes are written to
-the transient underlay. There is a regression test.
+the transient underlay. There is a regression test. However, this branch
+is blocked by working out what the desired behaviour is, on
+[[todo/autoindex_should_use_add__95__autofile]].
 
 > I wonder why this needs to be configurable? I suppose that gets back to
 > whether it makes sense to check these files in or not. The benefits of 
@@ -67,9 +70,11 @@ the transient underlay. There is a regression test.
 > commit clutter is really worth it.
 
 >> According to the last section of
->> [[todo/auto-create_tag_pages_according_to_a_template]], chrysn and
+>> [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] and
 >> Eric both feel rather strongly that it should be possible to
->> not commit any tags. I made it configurable because, as you point out,
+>> not commit any tags; in [[plugins/autoindex/discussion]],
+>> lollipopman and [[JoeRayhawk]] both requested the same for autoindex.
+>> I made it configurable because, as you point out,
 >> there are also reasons why it makes sense to check these
 >> automatically-created files in. I'm neutral on this, personally.
 >>
@@ -95,8 +100,8 @@ the transient underlay. There is a regression test.
 autoindex ignores pages in the transient underlay when deciding whether
 to generate an index.
 
-With the additional `transient-recentchanges` branch, new recent changes
-go in the transient underlay; I tested this manually.
+With the additional `ready/transient-recentchanges` branch, new recent
+changes go in the transient underlay; I tested this manually.
 
 Not done yet (in that branch, at least):
 
@@ -130,51 +135,57 @@ Not done yet (in that branch, at least):
 >> Here are some other things I'd like to think about first: --[[Joey]] 
 >>
 >> * There's a FIXME in autoindex.
-
->>> Right, the extra logic for preventing autoindex pages from being
->>> re-created. This is taking a while, so I'm going to leave out the
->>>> autoindex part for the moment. The FIXME is only relevant
->>>> because I tried to solve
->>>> [[todo/autoindex should use add__95__autofile]] first, but
->>>> strictly speaking, that's an orthogonal change. --s
+>>
+>>     > Right, the extra logic for preventing autoindex pages from being
+>>     > re-created. This is taking a while, so I'm going to leave out the
+>>     > autoindex part for the moment. The FIXME is only relevant
+>>     > because I tried to solve
+>>     > [[todo/autoindex should use add__95__autofile]] first, but
+>>     > strictly speaking, that's an orthogonal change. --s
 
 >> * Suggest making recentchanges unlink the transient page
 >>   first, and only unlink from the old location if it wasn't
 >>   in the transient location. Ok, it only saves 1 syscall :)
-
->>> Is an unlink() really that expensive? But, OK, fixed in the
->>> `transient-recentchanges` branch. --s
+>>
+>>   > Is an unlink() really that expensive? But, OK, fixed in the
+>>   > `ready/transient-recentchanges` branch. --s
 
 >> * Similarly it's a bit worrying for performance that it
 >>   needs to pull in and use `Cwd` on every ikiwiki startup now.
 >>   I really don't see the need; `wikistatedir` should
 >>   mostly be absolute, and ikiwiki should not chdir in ways
 >>   that break it anyway.
-
->>> The reason to make it absolute is that relative underlays
->>> are interpreted as relative to the base underlay directory,
->>> not the cwd.
->>>
->>> The updated `transient-only` branch only loads `Cwd` if
->>> the path is relative; an extra commit on branch
->>> `smcv/transient-relative` goes behind `add_underlay`'s
->>> back to allow use of a cwd-relative underlay. Which direction
->>> would you prefer? --s
+>>
+>>   > The reason to make it absolute is that relative underlays
+>>   > are interpreted as relative to the base underlay directory,
+>>   > not the cwd, by `add_underlay`.
+>>   >
+>>   > The updated `ready/transient-only` branch only loads `Cwd` if
+>>   > the path is relative; an extra commit on branch
+>>   > `smcv/transient-relative` goes behind `add_underlay`'s
+>>   > back to allow use of a cwd-relative underlay. Which direction
+>>   > would you prefer?
+>>   >
+>>   > I note in passing that [[plugins/autoindex]] and `IkiWiki::Render`
+>>   > both need to use `Cwd` and `File::Find` on every refresh, so
+>>   > there's only any point in avoiding `Cwd` for runs that don't
+>>   > actually refresh, like simple uses of the CGI. --s
 
 >> * Unsure about the use of `default_pageext` in the `change`
 >>   hook. Is everything in the transientdir really going
 >>   to use that pageext? Would it be better to look up the
 >>   complete source filename?
-
->>> At the moment everything in the transientdir will either
->>> have the `default_pageext` or be internal, although I
->>> did wonder whether to make [[plugins/contrib/album]]
->>> viewer pages optionally be `html`, for better performance
->>> when there's a very large number of photos.
->>>
->>> A more thorough garbage-collection mechanism would be to
->>> use File::Find on the transient directory; I'll get there
->>> eventually. --s
+>>
+>>   > I've updated `ready/transient` to do a more thorough GC by
+>>   > using File::Find on the transient directory. This does
+>>   > require `File::Find` and `Cwd`, but only when pages change,
+>>   > and `refresh` loads both of those in that situation anyway.
+>>   >
+>>   > At the moment everything in the transientdir will either
+>>   > have the `default_pageext` or be internal, although I
+>>   > did wonder whether to make [[plugins/contrib/album]]
+>>   > viewer pages optionally be `html`, for better performance
+>>   > when there's a very large number of photos. --s
 
 --------------------------