revert spam

[git.ikiwiki.info.git] / doc / bugs / transitive_dependencies.mdwn

diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
index d5571cb6a0967893f7457cdf4e0e801c8f71b5a7..c44fe7962ba4e90e864d955f7d378c61c56cadb9 100644 (file)
--- a/doc/bugs/transitive_dependencies.mdwn
+++ b/doc/bugs/transitive_dependencies.mdwn
@@ -1,5 +1,5 @@
 If a sidebar contains a map, or inline (etc), one would expect a
 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
+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
 rebuild. But this does not happen.
 
 If page A inlines page B, which inlines page C, a change to C will cause B


@@ -52,13 +52,43 @@ Downsides here:
   at least in my simple implementation, which re-runs the dependency
   resolution loop until no new pages are rebuilt.
   (I added an optimisation that gets it down to 1.5X as much work on
   at least in my simple implementation, which re-runs the dependency
   resolution loop until no new pages are rebuilt.
   (I added an optimisation that gets it down to 1.5X as much work on

-  average, still 2x as much worst case.)
+  average, still 2x as much worst case. I suppose building a directed
+  graph and traversing it would be theoretically more efficient.)

 * Causes extra work for some transitive dependencies that we don't
 * Causes extra work for some transitive dependencies that we don't

-  actually care about. For example, changing index causes
+  actually care about. This is amelorated, but not solved by 
+  the current work on [[todo/dependency_types]].
+  For example, changing index causes

   plugins/brokenlinks to update in the first pass; if there's a second
   plugins/brokenlinks to update in the first pass; if there's a second

-  pass, plugins/map is then updated, because it depends on plugins/brokenlinks.
+  pass, plugins/map is no longer updated (contentless dependencies FTW),
+  but plugins is, because it depends on plugins/brokenlinks.

   (Of course, this is just a special case of the issue that a real
   (Of course, this is just a special case of the issue that a real

-  modification to plugins/brokenlinks causes an unnecessary update of plugins/map,
-  because we have only one kind of dependency.)
+  modification to plugins/brokenlinks causes an unnecessary update of
+  plugins, and could be solved by adding more dependency types.)

 
 

---[[Joey]] 
+[[done]] --[[Joey]] 
+
+> Some questions/comments...  I've thought about this a lot for [[todo/tracking_bugs_with_dependencies]].
+> 
+>  * When you say that anything that causes a rebuild of B is treated as a change of B, are you: i) Treating
+> any rebuild as a change, or ii) Treating any rebuild that gives a new result as a change?  Option ii) would
+> lead to fewer rebuilds.  Implementation is easy: when you're about to rebuild a page, load the old rendered html in.  Do the rebuild.  Compare
+> the new and old html.  If there is a difference, then mark that page as having changed.  If there is no difference
+> then you don't need to mark that pages as changed, even though it has been rebuilt.  (This would ignore pages in meta-data that don't
+> cause changes in html, but I don't think that is a huge issue.)
+
+>> That is a good idea. I will have to look at it to see if the overhead of
+>> reading back in the html of every page before building actually is a
+>> win though. So far, I've focused on avoiding unnecessary rebuilds, and
+>> there is still some room for more dependency types doing so.
+>> (Particularly for metadata dependencies..) --[[Joey]] 
+
+>  * The second comment I have relates to cycles in transitive dependencies.  At the moment I don't think this is
+> possible, but with some additions it may well become so.  This could be problematic as it could lead to a)
+> updates that never complete, or b) it being theoretically unclear what the final result should be (i.e. you
+> can construct logical paradoxes in the system).  I think the point above about marking things as changed only when
+> the output actually changes fixes any cases that are well defined.  For logical paradoxes and infinite loops (e.g.
+> two pages that include each other), you might want to put a limit on the number of times you'll rebuild a page in any
+> given run of ikiwiki.  Say, only allow a page to rebuild twice on any run, regardless of whether a page it depends on changes.
+> This is not a perfect solution, but would be a good approximation. -- [[Will]]
+
+>> Ikiwiki only builds any given output file once per run, already. --[[Joey]]