analysis of how autofile and autoindex differ

master
http://smcv.pseudorandom.co.uk/ 2010-12-28 14:46:21 +00:00 committed by Joey Hess
parent 505d6925d4
commit 0fc36d36be
1 changed files with 67 additions and 2 deletions

View 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,74 @@ 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)
* 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