]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/bugs/transitive_dependencies.mdwn
test alternative header link name
[git.ikiwiki.info.git] / doc / bugs / transitive_dependencies.mdwn
index c61afe81e922947d9a2cc454752312fff5e072b6..c44fe7962ba4e90e864d955f7d378c61c56cadb9 100644 (file)
@@ -1,5 +1,5 @@
 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
@@ -25,9 +25,15 @@ 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 = change approach
+
+[[!template id=gitbranch branch=origin/transitive-dependencies author="[[joey]]"]]
+
+Another approach to fix it is 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
+rebuilt due to dependencies, and in turn this means A is rebuilt because B
 "changed". 
 
 This is essentially what is done with wikilinks now, and why, if a sidebar
@@ -40,8 +46,49 @@ here:
        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.
+Downsides here:
+
+* Means a minimum of 2x as much time spent resolving dependencies,
+  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. 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
+  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
+  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
+  modification to plugins/brokenlinks causes an unnecessary update of
+  plugins, and could be solved by adding more dependency types.)
+
+[[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]]
 
---[[Joey]] 
+>> Ikiwiki only builds any given output file once per run, already. --[[Joey]]