Remove docs and point to ones on dartlang.org.

app/views/doc/pub-get.html

Index: app/views/doc/pub-get.html
diff --git a/app/views/doc/pub-get.html b/app/views/doc/pub-get.html
deleted file mode 100644
index 454586e25bac81155a2930da88ca538739fc33d2..0000000000000000000000000000000000000000
--- a/app/views/doc/pub-get.html
+++ /dev/null
@@ -1,96 +0,0 @@
-<pre><code>$ pub get [--offline]
-</code></pre>
-
-<p>This command gets all the dependencies listed in the
-<a href="pubspec.html"><code>pubspec.yaml</code></a> file in the current working directory, as well as
-their <a href="glossary.html#transitive-dependency">transitive dependencies</a>, and places
-them in a <code>packages</code> directory located next to the pubspec. For example:</p>
-
-<pre><code>$ pub get
-Got dependencies!
-</code></pre>
-
-<p>Once the dependencies are acquired, they may be referenced in Dart code. For
-example, if a package depends on <code>unittest</code>:</p>
-
-<div class="highlight"><pre><code class="dart"><span class="k">import</span> <span class="s2">&quot;package:unittest/unittest.dart;</span>
-</code></pre></div>
-
-<p>When <code>pub get</code> gets new dependencies, it writes a
-<a href="glossary.html#lockfile">lockfile</a> to ensure that future gets will use the
-same versions of those dependencies. Application packages should check in the
-lockfile to source control; this ensures the application will use the exact same
-versions of all dependencies for all developers and when deployed to production.
-Library packages should not check in the lockfile, though, since they&rsquo;re
-expected to work with a range of dependency versions.</p>
-
-<p>If a lockfile already exists, <code>pub get</code> uses the versions of dependencies
-locked in it if possible. If a dependency isn&rsquo;t locked, pub will get the
-latest version of that dependency that satisfies all the <a href="glossary.html#version-constraint">version
-constraints</a>. This is the primary difference
-between <code>pub get</code> and <a href="pub-upgrade.html"><code>pub upgrade</code></a>, which always tries to
-get the latest versions of all dependencies.</p>
-
-<h2 id="getting-a-new-dependency">Getting a new dependency</h2>
-
-<p>If a dependency is added to the pubspec and then <code>pub get</code> is run, it will
-get the new dependency and any of its transitive dependencies and place them in
-the <code>packages</code> directory. However, it won&rsquo;t change the versions of any
-already-acquired dependencies unless that&rsquo;s necessary to get the new
-dependency.</p>
-
-<h2 id="removing-a-dependency">Removing a dependency</h2>
-
-<p>If a dependency is removed from the pubspec and then <code>pub get</code> is run, it will
-remove the dependency from the <code>packages</code> directory, thus making it
-unavailable for importing. Any transitive dependencies of the removed dependency
-will also be removed, as long as no remaining immediate dependencies also depend
-on them. Removing a dependency will never change the versions of any
-already-acquired dependencies.</p>
-
-<h2 id="linked-packages-directories">Linked <code>packages</code> directories</h2>
-
-<p>Every <a href="glossary.html#entrypoint">entrypoint</a> in a package needs to be next to a
-<code>packages</code> directory in order for it to import packages acquired by Pub.
-However, it&rsquo;s not convenient to put every entrypoint at the top level of the
-package alongside the main <code>packages</code> directory. You may have example scripts or
-tests that you want to be able to run from subdirectories.</p>
-
-<p><code>pub get</code> solves this issue by creating additional <code>packages</code> directories
-that link to the main <code>packages</code> directory at the root of your package. It
-assumes your package is laid out according to the <a href="package-layout.html">package layout
-guide</a>, and creates a linked <code>packages</code> directory in
-<code>bin/</code>, <code>test/</code>, and <code>example/</code>, as well as their subdirectories.</p>
-
-<h2 id="the-system-package-cache">The system package cache</h2>
-
-<p>Dependencies are not physically stored in the <code>packages</code> directory that pub
-creates. Dependencies downloaded over the internet, such as those from Git and
-<a href="http://pub.dartlang.org">pub.dartlang.org</a>, are stored in a system-wide cache
-and linked to from the <code>packages</code> directory. This means that if multiple
-packages use the same version of the same dependency, it will only need to be
-downloaded and stored locally once. It also means that it&rsquo;s safe to delete the
-<code>packages</code> directory without worrying about re-downloading packages.</p>
-
-<p>By default, the system package cache is located in the <code>.pub-cache</code> subdirectory
-of your home directory. However, it may be configured by setting the <code>PUB_CACHE</code>
-environment variable before running Pub.</p>
-
-<h2 id="getting-while-offline">Getting while offline</h2>
-
-<p>If you don&rsquo;t have network access, you can still run <code>pub get</code>. Since pub
-downloads packages to a central cache shared by all packages on your system, it
-can often find previous-downloaded packages there without needing to hit the
-network.</p>
-
-<p>However, by default, pub will always try to go online when you get if you
-have any hosted dependencies so that it can see if newer versions of them are
-available. If you don&rsquo;t want it to do that, pass the <code>--offline</code> flag when
-running pub. In this mode, it will only look in your local package cache and
-try to find a set of versions that work with your package from what&rsquo;s already
-available.</p>
-
-<p>Keep in mind that pub <em>will</em> generate a lockfile after it does this. If the
-only version of some dependency in your cache happens to be old, this will lock
-your app to that version. The next time you are online, you will likely want to
-run <a href="pub-upgrade.html"><code>pub upgrade</code></a> to upgrade to a later version.</p>