Ethan Atkins 272508596a Use one observer for all aggregated watch tasks ... There was a bug where sometimes a source file change would not trigger a new build if the change occurred during a build. Based on the logs, it seemed to be because a number of redundant events were generated for the same path and they triggered the anti-entropy constraint of the file event monitor. To fix this, I consolidated a number of observers of the global file tree repository into a single observer. This way, I am able to ensure that only one event is generated per file event. I also reworked the onEvent callback to only stamp the file once. It was previously stamping the modified source file for all of the aggregated tasks. In the sbt project running `~compile` meant that we were stamping a source file 22 times whenever the file changed. This actually uncovered a zinc issue though as well. Zinc computes and writes the hash of the source file to the analysis file after compilation has completed. If a source file is modified during compilation, then the new hash is written to the analysis file even when the compilation may have been made against the previous version of the file. Zinc will then refuse to re-compile that file until another change is made. I manually verified that in the sbt project if I ran `~compile` before this change and modified a file during compilation, then no event was triggered (there was a log message about the event being dropped due to the anti-entropy constraint though). After this change, if I changed a file during compilation, it seemed to always trigger, but due to the zinc bug, it didn't always re-compile.		2019-07-15 14:21:14 -07:00
..
src	Use one observer for all aggregated watch tasks	2019-07-15 14:21:14 -07:00
NOTICE	Add, configure & enforce file headers	2017-10-05 09:03:40 +01:00