implemented one fix in transitive-dependencies branch, but not really happy with it

diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
index c61afe81e922947d9a2cc454752312fff5e072b6..89f0d7085e86326a59e5be9b060095d6d454a6b4 100644 (file)
--- a/doc/bugs/transitive_dependencies.mdwn
+++ b/doc/bugs/transitive_dependencies.mdwn
@@ -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=master/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,17 @@ 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.
+* Causes extra work for some transitive dependencies that we don't
+  actually care about. For example, changing index causes
+  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.
+  (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.)

 
 --[[Joey]] 
 
 --[[Joey]]