diff --git a/Understanding-incremental-recompilation.md b/Understanding-incremental-recompilation.md
index 0f933e6..8861f37 100644
--- a/Understanding-incremental-recompilation.md
+++ b/Understanding-incremental-recompilation.md
@@ -107,5 +107,5 @@ Hence, adding explicit return types on classes with many dependencies might redu
 In Java adding a member does not require recompiling existing valid source code. The same should seemingly hold also in Scala, but this is not the case: implicit conversions might enrich class `Foo` with method `bar` without modifying class `Foo` itself through the [pimp-my-library pattern](http://www.artima.com/weblogs/viewpost.jsp?thread=179766) (see discussion in issue [#288](https://github.com/harrah/xsbt/issues/288) - XXX integrate more). However, if another method `bar` is introduced in class `Foo`, this method should be used in preference to the one added through implicit conversions. Therefore any class depending on `Foo` should be recompiled. One can imagine more fine-grained tracking of dependencies, but this is currently not implemented. 
 
 ## Further references
-The incremental compilation logic is implemented in https://github.com/harrah/xsbt/blob/0.13/compile/inc/Incremental.scala. Some related documentation for SBT 0.7 is available at: https://code.google.com/p/simple-build-tool/wiki/ChangeDetectionAndTesting.
+The incremental compilation logic is implemented in https://github.com/sbt/sbt/blob/0.13/compile/inc/src/main/scala/sbt/inc/Incremental.scala. Some related documentation for SBT 0.7 is available at: https://code.google.com/p/simple-build-tool/wiki/ChangeDetectionAndTesting.
 Some discussion on the incremental recompilation policies is available in issue [#322](https://github.com/harrah/xsbt/issues/322) and [#288](https://github.com/harrah/xsbt/issues/288).
\ No newline at end of file