From c614e5adb3214e290154902eacf6b27e595ac676 Mon Sep 17 00:00:00 2001 From: Duke Leto Date: Tue, 22 Jun 2021 00:41:34 +0000 Subject: [PATCH] Update 'doc/developer-notes.md' --- doc/developer-notes.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/developer-notes.md b/doc/developer-notes.md index 12a1dc9f9..e73e8bce9 100644 --- a/doc/developer-notes.md +++ b/doc/developer-notes.md @@ -2,9 +2,11 @@ Many times, you will want to do a "fresh sync" test, to verify code works when syncing from the genesis block, which is a different code path than a "partial sync" which means you already have part of blockchain history and are "catching up" to get in sync. -A "fresh sync" goes thru the Initial Blockchain Download (IBD) optimized codepath and is often faster than than rescanning all of history. Both ways of testing any important change should be done. +A "fresh sync" goes thru the Initial Blockchain Download (IBD) optimized codepath and is often faster than than rescanning all of history. Fresh sync and partial sync testing any important change should be done for all important changes. -One way is: +A fresh sync preserves peers.dat, so it will always be faster than a "fresh clone", which has to learn enough p2p peers to being syncing, which can often add many minutes to completing a sync. When code related to peers.dat changes (such in the `p2p` branch) then doing a fresh clone is needed to fully test it. + +One way fresh sync is: ``` cd ~/.komodo/HUSH3