doc: document the reason for --no-renumber

[public-inbox.git] / Documentation / public-inbox-v2-format.pod

diff --git a/Documentation/public-inbox-v2-format.pod b/Documentation/public-inbox-v2-format.pod
index 05ef32a9b6782cf79469d2206c20d51d4bf636bd..bc58074e0de56fdfe0c791fea2ed44ad1a5eef2d 100644 (file)
--- a/Documentation/public-inbox-v2-format.pod
+++ b/Documentation/public-inbox-v2-format.pod
@@ -109,7 +109,7 @@ code paths.
 
 The performance of the storage device is now the bottleneck on
 larger multi-core systems.  In our experience, performance is
-improves with high-quality and high-quantity solid-state storage.
+improved with high-quality and high-quantity solid-state storage.
 Issuing TRIM commands with L<fstrim(8)> was necessary to maintain
 consistent performance while developing this feature.
 
@@ -117,6 +117,10 @@ Rotational storage devices are NOT recommended for indexing of
 large mail archives; but are fine for backup and usable for
 small instances.
 
+Our use of the L</OVERVIEW DB> requires Xapian document IDs to
+remain stable.  Thus, use of L<xapian-compact(1)> and
+L<copydatabase(8)> require the use of C<--no-renumber> switch.
+
 =head2 OVERVIEW DB
 
 Towards the end of v2 development, it became apparent Xapian did
@@ -210,7 +214,7 @@ for all non-atomic operations.
 
 =head1 HEADERS
 
-Same handling as with v1, except the Message-ID header will will
+Same handling as with v1, except the Message-ID header will
 be generated if not provided or conflicting.  "Bytes", "Lines"
 and "Content-Length" headers are stripped and not allowed, they
 can interfere with further processing.