diff --git a/README.md b/README.md
index 5de2455..9ac156e 100644
--- a/README.md
+++ b/README.md
@@ -51,11 +51,11 @@ and how they interact with the message store, message index and so on.
 ### Variable Queue Guide ###
 
 Ultimately, messages end up queued at the
-[backing queue](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_backing_queue.erl). From
+[backing queue](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_backing_queue.erl). From
 here they can be retrieved, acked, purged, and so on. The most common
 implementation of the backing queue behaviour is the
 `rabbit_variable_queue`
-[module](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_variable_queue.erl),
+[module](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_variable_queue.erl),
 explained in the following guide:
 
 [Variable Queue](./variable_queue.md)
diff --git a/authorization_and_authentication.md b/authorization_and_authentication.md
index b17e476..49134b9 100644
--- a/authorization_and_authentication.md
+++ b/authorization_and_authentication.md
@@ -25,7 +25,7 @@ In practice in 99% of cases only two mechanisms are used:
 
  * `PLAIN` (a set of credentials such as username and password)
  * `EXTERNAL`, which assumes authentication happens out of band (not performed
-   by RabbitMQ authN backends), usually [using x509 (TLS) certificates](https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl).
+   by RabbitMQ authN backends), usually [using x509 (TLS) certificates](https://github.com/rabbitmq/rabbitmq-server/tree/master/deps/rabbitmq_auth_mechanism_ssl).
    This mechanism ignores client-provided credentials and relies on TLS [peer certificate chain
    verification](https://tools.ietf.org/html/rfc6818).
 
@@ -33,7 +33,7 @@ When a client connection reaches [authentication stage](https://github.com/rabbi
 and supported by the server is selected. The mechanism module then checks whether it can
 be applied to a connection (e.g. the TLS-based mechanism will reject non-TLS connections).
 
-An authentication mechanism is a module that implements the [rabbit_auth_mechanism](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_auth_mechanism.erl) behaviour, which includes
+An authentication mechanism is a module that implements the [rabbit_auth_mechanism](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/rabbit_auth_mechanism.erl) behaviour, which includes
 3 functions:
 
  * `init/1`: self-explanatory
diff --git a/basic_publish.md b/basic_publish.md
index b7ba2bd..df86547 100644
--- a/basic_publish.md
+++ b/basic_publish.md
@@ -70,7 +70,7 @@ called `"my_exchange"`, we will end up with the following record:
 
 Resources like that one are used everywhere in RabbitMQ, so it's a
 good idea to study their parts in the
-[rabbit_types](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_types.erl)
+[rabbit_types](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/rabbit_types.erl)
 module where this declarations are defined.
 
 Once we have the exchange record, `basic.publish` will use it to see
diff --git a/deliver_to_queues.md b/deliver_to_queues.md
index 1b0675e..a0768e2 100644
--- a/deliver_to_queues.md
+++ b/deliver_to_queues.md
@@ -39,7 +39,7 @@ via the `delegate` framework. The Erlang message will have this shape:
 ```
 
 You can learn more about the delegate framework
-[here](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/delegate.erl#L19).
+[here](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/delegate.erl#L10).
 
 ## AMQQueue Process Message Handling ##
 
@@ -51,7 +51,7 @@ callback will ack the `credit_flow` issued in above, and it will
 monitor the message sender. The message sender is usually the
 `rabbit_channel` that received the process. This pid is tracked using
 the
-[pmon module](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/pmon.erl). The
+[pmon module](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/pmon.erl). The
 state is kept as part of the `senders` field in the gen_server state
 record. Once the message sender is accounted for the delivery is
 passed to the function `deliver_or_enqueue/3`. There is where the
@@ -171,7 +171,7 @@ channel forever if a queue that's blocking it is actually down.
 
 Take a look at the `handle_info` channel callback for the case when a
 `DOWN` message is
-[received](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_channel.erl#L578).
+[received](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_channel.erl#L818).
 
 ### Process Mandatory Messages ###
 
diff --git a/exchange_decorators.md b/exchange_decorators.md
index aaf82df..78c1e6a 100644
--- a/exchange_decorators.md
+++ b/exchange_decorators.md
@@ -8,11 +8,11 @@ alone the whole routing logic to the underlying exchange.
 Decorators are usually associated with exchanges via policies.
 
 See the `active_for/1`
-[callback](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_exchange_decorator.erl#L70)
+[callback](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_exchange_decorator.erl#L70)
 to understand which functions on the exchange would be decorated.
 
 Take a look at the
-[Sharding Plugin](https://github.com/rabbitmq/rabbitmq-sharding/blob/master/src/rabbit_sharding_exchange_decorator.erl)
+[Sharding Plugin](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_sharding/src/rabbit_sharding_exchange_decorator.erl)
 and the
-[Federation Plugin](https://github.com/rabbitmq/rabbitmq-federation/blob/master/src/rabbit_federation_exchange.erl)
+[Federation Plugin](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_federation/src/rabbit_federation_exchange.erl)
 to see how exchange decorators are implemented.
diff --git a/interceptors.md b/interceptors.md
index 3066a89..a8e49e1 100644
--- a/interceptors.md
+++ b/interceptors.md
@@ -4,7 +4,7 @@ Interceptors are modules implemented as behaviours that allow plugin
 authors to intercept and modify AMQP methods before they are handled
 by the channel process. They were originally created for the
 development of the
-[Sharding Plugin](https://github.com/rabbitmq/rabbitmq-sharding/blob/master/README.extra.md#intercepted-channel-behaviour)
+[Sharding Plugin](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_sharding/README.extra.md#intercepted-channel-behaviour)
 to facilitate mapping queue names as specified by users vs. the actual
 names used by sharded queues. Another plugin using interceptors is the
 [Message Timestamp Plugin](https://github.com/rabbitmq/rabbitmq-message-timestamp)
@@ -16,7 +16,7 @@ behaviour. The most important callback is `intercept/3` where an
 interceptor will be provided with the original AMQP method record that
 the channel should process, the AMQP method content, if any, and the
 interceptor state (see
-[init/1](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_channel_interceptor.erl#L36)). This
+[init/1](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_channel_interceptor.erl#L36)). This
 callback should take the AMQP method that was passed to it, and the
 content, and modify it accordingly. For example, the Sharding Plugin
 will receive a `basic.consume` method, with a sharded queue called
diff --git a/internal_events.md b/internal_events.md
index e106209..9afff64 100644
--- a/internal_events.md
+++ b/internal_events.md
@@ -61,7 +61,7 @@ dummy usernames are used, e.g. `rmq-internal` or `rmq-cli`.
 
 ## rabbitmq-event-exchange Plugin
 
-[rabbitmq-event-exchange](https://github.com/rabbitmq/rabbitmq-event-exchange) is a plugin that consumes internal events
+[rabbitmq-event-exchange](https://github.com/rabbitmq/rabbitmq-server/tree/master/deps/rabbitmq_event_exchange) is a plugin that consumes internal events
 and re-publishes them to a topic exchange, thus exposing the events
 to clients (applications).
 
diff --git a/mandatory_message_handling.md b/mandatory_message_handling.md
index 02db17a..e13c48f 100644
--- a/mandatory_message_handling.md
+++ b/mandatory_message_handling.md
@@ -7,9 +7,13 @@ see how the channel handles mandatory messages.
 
 ## Tracking Mandatory Messages ##
 
+Note: Implementation was changed in
+[3.8.0](https://github.com/rabbitmq/rabbitmq-server/pull/1831),
+removing the dtree strucutre described below.
+
 Mandatory messages are tracked in the `mandatory` field of the
 channel's state record. Messages are tracked using our own
-[dtree](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/dtree.erl)
+[dtree](https://github.com/rabbitmq/rabbitmq-server/blob/v3.7.28/src/dtree.erl)
 data structure. As explained in that module documentation, entries on
 the _dual-index tree_ are stored using a primary key, a set of
 secondary keys, and a value. In the case of tracking mandatory
diff --git a/metrics_and_management_plugin.md b/metrics_and_management_plugin.md
index dabb1c7..9121394 100644
--- a/metrics_and_management_plugin.md
+++ b/metrics_and_management_plugin.md
@@ -28,7 +28,7 @@ There are four main components:
 Core metrics are implemented in the rabbitmq server itself consisting of
 a set of of ETS tables storing either counters or proplists containing details
 or metrics of various entities. The schema of each table is documented in
-[rabbit_core_metrics.hrl](https://github.com/rabbitmq/rabbitmq-common/blob/master/include/rabbit_core_metrics.hrl)
+[rabbit_core_metrics.hrl](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/include/rabbit_core_metrics.hrl)
 in `rabbitmq-common`.
 
 Mostly counters that are incremented in real-time as message interactions occur
@@ -45,7 +45,7 @@ memory overhead in relation to the number of active entities in the system.
 
 ## Management Agent
 
-[rabbitmq-managment-agent](https://github.com/rabbitmq/rabbitmq-management-agent) is responsible for turning core metrics into
+[rabbitmq-managment-agent](https://github.com/rabbitmq/rabbitmq-server/tree/master/deps/rabbitmq_management_agent) is responsible for turning core metrics into
 data structures suitable for `rabbitmq-management` consumption.  This is
 done on a per node basis. There are no inter-node communications involved.
 
@@ -53,7 +53,7 @@ The management agent runs a set of metrics collector processes. There is one
 process per core metrics table. Each collector periodically read its associated
 core metrics table and performs some table-specific processing which produces
 new data points to be inserted into the management metrics tables (defined in
-[rabbitmq_mgmt_metrics.hrl](https://github.com/rabbitmq/rabbitmq-management-agent/blob/master/include/rabbit_mgmt_metrics.hrl)).
+[rabbitmq_mgmt_metrics.hrl](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_management_agent/include/rabbit_mgmt_metrics.hrl)).
 The collection interval is determined by the smallest configured retention intervals.
 
 In addition to the collector processes there is a garbage collection event
@@ -76,7 +76,7 @@ This has no effect on the user but test suites that use the HTTP API would often
 
 ### exometer_slide
 
-The [exometer_slide](https://github.com/rabbitmq/rabbitmq-management-agent/blob/master/src/exometer_slide.erl)
+The [exometer_slide](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_management_agent/src/exometer_slide.erl)
 module is a key part of the management stats processing.
 It allows us to reasonably efficiently store a sliding window of incoming metrics
 and also perform various processing on this window. It was extracted from the
@@ -93,7 +93,7 @@ The `rabbitmq-management` plugin is now mostly a fairly thin HTTP API layer.
 
 It also handles the distributed querying and stats merging logic. When a stats
 request comes in the plugin contacts each node in parallel for a set of "raw"
-stats (typically `exometer_slide` instances). It uses the [delegate](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/delegate.erl)
+stats (typically `exometer_slide` instances). It uses the [delegate](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/delegate.erl)
 module for this and has it's own `delegate` supervision tree to avoid affecting
 the one used for core rabbit delegations. Once stats for
 each node has been collected it merges the data then proceeds with processing
diff --git a/publisher_confirms.md b/publisher_confirms.md
index 7c25bce..881cd97 100644
--- a/publisher_confirms.md
+++ b/publisher_confirms.md
@@ -10,6 +10,10 @@ documentation in order to understand the feature.
 
 ## Tracking Confirms ##
 
+Note: Implementation was slightly changed in
+[3.8.0](https://github.com/rabbitmq/rabbitmq-server/pull/1893),
+replacing the dtree strucutre described below.
+
 Confirms work a bit differently than mandatory messages and
 `basic.return`. In the case of mandatory messages we only need to send
 a `basic.return` if the message can't be routed, but for publisher
@@ -19,7 +23,7 @@ fields in the channel's state record in order to track this
 information.
 
 The first one is a
-[dtree](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/dtree.erl)
+[dtree](https://github.com/rabbitmq/rabbitmq-server/blob/v3.7.28/src/dtree.erl)
 stored in the field `unconfirmed`, which keeps track of the `MsgSeqNo`
 associated with the QPids to which the message was delivered and
 the Exchange Name used to publish the message. As explained in the
diff --git a/queue_decorators.md b/queue_decorators.md
index f7742ba..33d5095 100644
--- a/queue_decorators.md
+++ b/queue_decorators.md
@@ -12,7 +12,7 @@ or by the federation plugin, to know when to move messages across
 [federated queues](https://www.rabbitmq.com/federated-queues.html).
 
 Decorators need to implement the `rabbit_queue_decorator`
-[behaviour](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_queue_decorator.erl)
+[behaviour](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_queue_decorator.erl)
 and are usually associated with queues via policies.
 
 A Queue decorator can receive notifications of the following events:
diff --git a/queues_and_message_store.md b/queues_and_message_store.md
index 30dc804..9b552c1 100644
--- a/queues_and_message_store.md
+++ b/queues_and_message_store.md
@@ -156,7 +156,7 @@ should be atomic.
 Message store logic assumes that lookup operations for non-existent message
 locations (if message is not yet written to file) are cheap.
 
-See the [message store index behaviour module](https://github.com/rabbitmq/rabbitmq-common/blob/master/src/rabbit_msg_store_index.erl) for more details.
+See the [message store index behaviour module](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/rabbit_msg_store_index.erl) for more details.
 
 The message store also needs to be garbage collected. There's an extra
 process for GC (so that GC can lock some files and the message store
diff --git a/transactions_in_exchange_modules.md b/transactions_in_exchange_modules.md
index a07b0b2..e2e0409 100644
--- a/transactions_in_exchange_modules.md
+++ b/transactions_in_exchange_modules.md
@@ -19,14 +19,14 @@ The question is, what's the purpose of that transaction parameter?
 This is related to how RabbitMQ runs Mnesia transactions for its
 internal bookkeeping:
 
-[https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_misc.erl#L546](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_misc.erl#L546)
+[rabbit_misc:execute_mnesia_transaction/2](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit_common/src/rabbit_misc.erl#L586)
 
 As you can see in that code there's this PrePostCommitFun which is
 called in Mnesia transaction context, and after the transaction has
 run.
 
-So here for example:
-[https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange.erl#L176](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange.erl#L176)
+So here for example: in
+[rabbit_exchange:declare/7](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_exchange.erl#L143)
 the create callback from the exchange is called inside a Mnesia
 transaction, and outside of afterwards.
 
@@ -34,9 +34,9 @@ You can see this in action/understand the usefulness of it when
 considering an exchange like the topic exchange which keeps track of
 its own data structures:
 
-[https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L54](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L54)
-[https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L64](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L64)
-[https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L69](https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_exchange_type_topic.erl#L69)
+[rabbit_exchange_type_topic:delete/3](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_exchange_type_topic.erl#L49)
+[rabbit_exchange_type_topic:add_binding/3](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_exchange_type_topic.erl#L59)
+[rabbit_exchange_type_topic:remove_bindings/3](https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_exchange_type_topic.erl#L64)
 
 Deleting the exchange, adding or removing bindings, are all done
 inside a Mnesia transaction for consistency reasons.