diff options
| -rw-r--r-- | doc/bugs/transitive_dependencies.mdwn | 47 | ||||
| -rw-r--r-- | doc/plugins/sidebar/discussion.mdwn | 2 | ||||
| -rw-r--r-- | doc/todo/tracking_bugs_with_dependencies.mdwn | 5 |
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 |