diff options
| author | http://www.cse.unsw.edu.au/~willu/ <http://www.cse.unsw.edu.au/~willu/@web> | 2009-10-08 21:30:17 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2009-10-08 21:30:17 -0400 |
| commit | d73c54b9a7406f4f8d23b2a36e1968bba70f1089 (patch) | |
| tree | 960c921cb7d08ea62bc0738cf77bb22bc77852b2 /doc/bugs/transitive_dependencies.mdwn | |
| parent | a198c89e8f968549416d3871bddafa831240e6b8 (diff) | |
| download | ikiwiki-d73c54b9a7406f4f8d23b2a36e1968bba70f1089.tar ikiwiki-d73c54b9a7406f4f8d23b2a36e1968bba70f1089.tar.gz | |
comments on cycles in the dependency graph
Diffstat (limited to 'doc/bugs/transitive_dependencies.mdwn')
| -rw-r--r-- | doc/bugs/transitive_dependencies.mdwn | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn index 9586bc9b0..bdad67f60 100644 --- a/doc/bugs/transitive_dependencies.mdwn +++ b/doc/bugs/transitive_dependencies.mdwn @@ -66,3 +66,20 @@ Downsides here: plugins, and could be solved by adding more dependency types.) --[[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.) +> * 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]] |