summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/bugs/transitive_dependencies.mdwn47
-rw-r--r--doc/plugins/sidebar/discussion.mdwn2
-rw-r--r--doc/todo/tracking_bugs_with_dependencies.mdwn5
3 files changed, 50 insertions, 4 deletions
diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
new file mode 100644
index 000000000..c61afe81e
--- /dev/null
+++ b/doc/bugs/transitive_dependencies.mdwn
@@ -0,0 +1,47 @@
+If a sidebar contains a map, or inline (etc), one would expect a
+change/add/remove of any of the mapped/inlined pages to cause a full wiki
+rebuild. But this does not happen.
+
+If page A inlines page B, which inlines page C, a change to C will cause B
+to be updated, but A will not "notice" that this means A needs to be
+updated.
+
+One way to look at this bug is that it's a bug in where dependencies are
+recorded when preprocessing the rendered or sidebar page. The current code
+does:
+
+ add_depends($params{page}, $somepage);
+
+Where `$params{page}` is page B. If this is changed to `$params{destpage}`,
+then the dependency is added to page A, and updates to C cause it to
+change. This does result in the page A's getting lots more dependency info
+recorded than before (essentially a copy of all the B's dependency info).
+
+It's also a fragile, since all plugins that handle dependencies have to be
+changed, and do this going forward. And it seems non-obvious that this should
+be done. Or really, whether to use `page` or `destpage` there. Currently,
+making the "wrong" choice and using `destpage` instead of `page` (which nearly
+everything uses) will just result in semi-redundant dependency info being
+recorded. If we make destpage mandatory to fix this, goofing up will lead to
+this bug coming back. Ugh.
+
+Another approach to fix it could be to say that anything that causes a
+rebuild of B is treated as a change of B. Then when C is changed, B is
+rebuilt due to dependencies, and in turn this means A is rebuild because B
+"changed".
+
+This is essentially what is done with wikilinks now, and why, if a sidebar
+links to page C, add/remove of C causes all pages to be rebuilt, as seen
+here:
+
+ removing old page meep
+ building sidebar.mdwn, which links to meep
+ building TourBusStop.mdwn, which depends on sidebar
+ building contact.mdwn, which depends on sidebar
+ ...
+
+The only downside I can see with this approach is that it involves more work.
+Does the dep resolver have to keep looping until no new pages are rebuilt?
+Seems worth a try to implement this approach.
+
+--[[Joey]]
diff --git a/doc/plugins/sidebar/discussion.mdwn b/doc/plugins/sidebar/discussion.mdwn
index 78af3525c..eb441529c 100644
--- a/doc/plugins/sidebar/discussion.mdwn
+++ b/doc/plugins/sidebar/discussion.mdwn
@@ -1,3 +1,5 @@
> Warning: Any change to the sidebar will cause a rebuild of the whole wiki, since every page includes a copy that has to be updated. This can especially be a problem if the sidebar includes inline or map directives, since any changes to pages inlined or mapped onto the sidebar will change the sidebar and cause a full wiki rebuild.
I tried exactly that, namely having an inline in my sidebar to include an rss feed from some other side. I think the complete wiki rebuild should be doable every few days when a new article appears in that feed. But contrary to that warning there is no complete wiki rebuild, only the sidebar page is rebuilt by the "ikiwiki --aggregate" from cron. Is that a bug or a feature?
+
+> It's a bug, discussed in [[bugs/transitive_dependencies]]. --[[Joey]]
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index bfdbf0875..3894df5f6 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -472,10 +472,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
>>>>> possibly by adding a dependency of the second type along with the dependency of the first type.
>>>>>> An example of the current system not tracking enough data is
->>>>>> where A inlines B which inlines C. A change to C will cause B to
->>>>>> rebuild, but A will not "notice" that B has implicitly changed.
->>>>>> That example suggests it might be fixable without explicitly storing
->>>>>> data, by causing a rebuild of B to be treated as a change to B.
+>>>>>> described in [[bugs/transitive_dependencies]].
>>>>>> --[[Joey]]
>>>>> The second type of dependency is a little more tricky. For each page, we'd need a list of pagespecs that