Merge branch 'master' into transitive-dependencies

2 files changed, 27 insertions, 5 deletions

diff --git a/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn b/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn
index 395c7789e..d07b2381d 100644
--- a/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn
+++ b/doc/bugs/brokenlinks_accumulates_duplicate_items.mdwn
@@ -18,3 +18,8 @@ ikiwiki version 3.14159265.
 > If you can get to the problem after rebuilding with the current ikiwiki, 
 > and then refreshing a few times, I guess I will need a copy of the wiki
 > source and the `.ikiwiki` directory to reproduce this. --[[Joey]] 
+
+>> Hi Joey, thanks for your response. I've reproduced it post rebuild and after having ran ikiwiki-transition and many refreshes (both resulting from content changes and otherwise) unfortunately, with ikiwiki 3.14159265 (different machine to above report, though). I will contact you privately to provide a git URL and a copy of my .ikiwiki. -- [[Jon]]
+
+>>> Found the bug that was causing duplicates to get in, and fixed it.
+>>> [[done]] --[[Joey]] 
diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
index c61afe81e..546f4f3aa 100644
--- 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.
 
-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,19 @@ 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.)
+* 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|todo/dependency_types]].)
 
 --[[Joey]]