add bug about transitive dependencies

diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
new file mode 100644 (file)
index 0000000..c61afe8
--- /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 78af3525cbfa1f94055bc862389d14aa215000d0..eb441529c11ad6cef7be6d5e50b8f8fecf20eb6a 100644 (file)
--- 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?
 > 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 bfdbf0875e08bcad2572a841a8fe6ad16295fe30..3894df5f6e8525103b27ec00b1f405bc77be6829 100644 (file)
--- 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 
 >>>>> 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
 >>>>>> --[[Joey]] 
 
 >>>>> The second type of dependency is a little more tricky.  For each page, we'd need a list of pagespecs that