aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/transitive_dependencies.mdwn
diff options
context:
space:
mode:
authorJoey Hess <joey@gnu.kitenet.net>2009-10-08 22:31:13 -0400
committerJoey Hess <joey@gnu.kitenet.net>2009-10-08 22:31:13 -0400
commit0e2ce171c9e897b6b55d31cfeff7566f7adab7b8 (patch)
tree67e689ab1cac119ed819c1a7dae3fa613d395508 /doc/bugs/transitive_dependencies.mdwn
parentd73c54b9a7406f4f8d23b2a36e1968bba70f1089 (diff)
downloadikiwiki-0e2ce171c9e897b6b55d31cfeff7566f7adab7b8.tar
ikiwiki-0e2ce171c9e897b6b55d31cfeff7566f7adab7b8.tar.gz
response
Diffstat (limited to 'doc/bugs/transitive_dependencies.mdwn')
-rw-r--r--doc/bugs/transitive_dependencies.mdwn9
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn
index bdad67f60..70b5fb4d4 100644
--- a/doc/bugs/transitive_dependencies.mdwn
+++ b/doc/bugs/transitive_dependencies.mdwn
@@ -75,6 +75,13 @@ Downsides here:
> 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
@@ -83,3 +90,5 @@ Downsides here:
> 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]]