Remove legacy section on mercurial

src/guide/cloning-the-jdk.md

@@ -7,7 +7,7 @@
 * [Skara Documentation](https://wiki.openjdk.org/display/SKARA)
 :::
 
-The complete source code for the JDK is hosted at [GitHub](https://github.com). You can browse the code directly in the [openjdk/jdk repository](https://github.com/openjdk/jdk), or download the code for offline browsing, editing, and building using `git clone`.
+After the initial release of the JDK source code into OpenJDK in 2007 the OpenJDK project moved from TeamWare to using Mercurial. Starting in 2019 the source revision control has been moved to Git. The complete source code for the JDK is today hosted at [GitHub](https://github.com). You can browse the code directly in the [openjdk/jdk repository](https://github.com/openjdk/jdk), or download the code for offline browsing, editing, and building using `git clone`.
 
     $ git clone https://github.com/openjdk/jdk.git
 

src/guide/testing-the-jdk.md

@@ -179,6 +179,10 @@ In case of failures in the GHA it's always a good start to try to reproduce the
 
 Please keep in mind that the tier 1 tests run by the GHA should only be seen as a smoke test that finds the most critical breakages, like build errors or if the JDK is DOA. These tests can never replace the targeted testing that you always must do on your changes. There are several areas of the JDK that aren't part of tier 1 at all. To see exactly what tier 1 includes, please see the various TEST.groups files that you will find in the subdirectories of [`jdk/test/`](https://github.com/openjdk/jdk/tree/master/test).
 
+::: {.note}
+In the past there used to be a sandbox repository that could be used for testing purposes. With the move to Git this has been replaced by GitHub Actions.
+:::
+
 ## Excluding a test
 
 Sometimes tests break. It could be e.g. due to bugs in the test itself, due to changed functionality in the code that the test is testing, or changes in the environment where the test is executed. While working on a fix, it can be useful to stop the test from being executed in everyone else's testing to reduce noise, especially if the test is expected to fail for more than a day. There are two ways to stop a test from being run in standard test runs: ProblemListing and using the `@ignore` keyword. Removing tests isn't the standard way to remove a failure. A failing test is often a regression and should ideally be handled with high urgency.
@@ -369,23 +373,6 @@ index 4961acb2126..399e7cc311f 100644
  [online documentation](https://openjdk.org/groups/build/doc/building.html),
 ~~~
 
-### How to work with Mercurial when a change is backed out
-
-In order to backout a change, the `hg backout` command is recommended, which essentially applies the anti-delta of the change. Make sure you perform the backout in the most upstream repository the change has escaped to.
-
-~~~
-hg backout [OPTION]... [-r] REV
-
-reverse effect of earlier changeset
-
-    Prepare a new changeset with the effect of REV undone in the current
-    working directory.
-
-    If REV is the parent of the working directory, then this new changeset is
-    committed automatically. Otherwise, hg needs to merge the changes and the
-    merged result is left uncommitted.
-~~~
-
 ## Backing out a backport
 
 In rare cases it may be necessary to back out a backport from an update release without backing out the original fix in mainline. This will require a somewhat different procedure and will result in a small mess in JBS. It's extremely important to add comments in all relevant issues explaining exactly what's happened.

src/guide/working-with-pull-requests.md

@@ -122,14 +122,29 @@ Webrev refers to both the tool used to create them and its output. The script, [
 
 On the GitHub reviews you will find links to webrevs. These are automatically generated by the bot and are provided as a complement for those who prefer this style of code review. Many OpenJDK developers are used to the webrevs as this was the default way to provide code for review before OpenJDK moved to GitHub. Though webrevs are mainly deprecated today, they used to be a central part of OpenJDK development and you may still see people use the word as a synonym for code review, so they do deserve to be mentioned here as well.
 
-## File storage for OpenJDK artifacts - `cr.openjdk.java.net`
+## File storage for OpenJDK artifacts - `cr.openjdk.org`
 
-The `cr.openjdk.java.net` server provides storage and display of code review materials such as webrevs and other artifacts related to the OpenJDK Community. This area can also be used to store design documents and other documentation related OpenJDK but not related to any specific project that have an OpenJDK wiki space for such purposes.
+The `cr.openjdk.org` server provides storage and display of code review materials such as webrevs and other artifacts related to the OpenJDK Community. This area can also be used to store design documents and other documentation related OpenJDK but not related to any specific project that have an OpenJDK wiki space for such purposes.
 
-Any OpenJDK Author can publish materials on the `cr.openjdk.java.net` server. Users can upload files to temporary storage using secure methods (`rsync`, `scp`, and `sftp`).
+Any OpenJDK Author can publish materials on the `cr.openjdk.org` server. Users can upload files to temporary storage using secure methods (`rsync`, `scp`, and `sftp`).
 
 This site is for open source materials related to the OpenJDK Community only. Users uploading inappropriate materials will lose access and the material will be deleted. Please review the [Terms of Use](https://openjdk.org/legal/terms.html) before using this server.
 
+### Get your SSH key installed
+
+To use `cr.openjdk.org` you'll need to get an SSH key installed. See [Generating an SSH key] for guidance on how to generate a key. Your public key (`~/.ssh/id_rsa.pub`) should be mailed as an attachment along with your JDK username to [keys@openjdk.org](mailto:keys@openjdk.org). An administrator will install your key on the server and notify you on completion. This process may take a couple of days.
+
+::: {.note}
+Users behind a SOCKS firewall can add a directive to the `~/.ssh/config` file to connect to the OpenJDK server:
+
+    Host *.openjdk.org
+    ProxyCommand /usr/lib/ssh/ssh-socks5-proxy-connect -h [socks_proxy_address] %h %p
+
+See the `ssh-socks5-proxy-connect` man page and `ssh-config` man page for more information. Other systems may require proxy access via other programs. Some Linux distributions provide the `corkscrew` package which provides ssh access through HTTP proxies.
+
+**It's recommended that all users check with their network administrators before installing any kind of TCP forwarding tool on their network. Many corporations and institutions have strict security policies in this area.**
+:::
+
 ::: {.box}
 [To the top](#){.boxheader}
 :::

src/toc.conf

@@ -14,7 +14,6 @@ release-notes.md
 the-jdk-release-process.md
 project-maintenance.md
 hotspot-development.md
-working-with-the-legacy-mercurial-servers.md
 code-owners.md
 about-this-guide.md
 glossary.md