convert add_depends to use influences

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

diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
index c61afe81e922947d9a2cc454752312fff5e072b6..0a2e9ec2896176658a2a94f7c44b5921d54b03b8 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


@@ -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.
 
 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
 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
 "changed". 
 
 This is essentially what is done with wikilinks now, and why, if a sidebar


@@ -40,8 +46,23 @@ here:
        building contact.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.
+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.)

 
 

---[[Joey]] 
+[[done]] --[[Joey]]