Merge remote-tracking branch 'origin/newspeak' into xcpdb

* origin/newspeak:
  comments: replace "partition" with "shard"
  t/xcpdb-reshard: use 'shard' term in local variables
  xapcmd: favor 'shard' over 'part' in local variables
  search: use "shard" for local variable
  v2writable: use "epoch" consistently when referring to git repos
  adminedit: "part" => "shard" for local variables
  v2writable: rename local vars to match Xapian terminology
  v2writable: avoid "part" in internal subs and fields
  search*: rename {partition} => {shard}
  xapcmd: update comments referencing "partitions"
  v2: rename SearchIdxPart => SearchIdxShard
  inboxwritable: s/partitions/shards/ in local var
  tests: change messages to use "shard" instead of partition
  v2writable: rename {partitions} field to {shards}
  v2writable: count_partitions => count_shards
  searchidxpart: start using "shard" in user-visible places
  rename reference to git epochs as "partitions"
  admin|xapcmd: user-facing messages say "shard"
  v2writable: update comments regarding xcpdb --reshard
  doc: rename our Xapian "partitions" to "shards"

1 files changed, 5 insertions, 6 deletions

diff --git a/Documentation/public-inbox-xcpdb.pod b/Documentation/public-inbox-xcpdb.pod
index fd8770a4..a13c4efa 100644
--- a/Documentation/public-inbox-xcpdb.pod
+++ b/Documentation/public-inbox-xcpdb.pod
@@ -21,7 +21,7 @@ L<public-inbox-watch(1)> or L<public-inbox-mda(1)>.
 =item --compact
 
 In addition to performing the copy operation, run L<xapian-compact(1)>
-on each Xapian partition after copying but before finalizing it.
+on each Xapian shard after copying but before finalizing it.
 Compared to the cost of copying a Xapian database, compacting a
 Xapian database takes only around 5% of the time required to copy.
 
@@ -32,14 +32,13 @@ the compaction to take hours at-a-time.
 
 =item --reshard=N / -R N
 
-Repartition the Xapian database on a L<v2|public-inbox-v2-format(5)>
-inbox to C<N> partitions.  Since L<xapian-compact(1)> is not suitable
-for merging, users can rely on this switch to repartition the
+Reshard the Xapian database on a L<v2|public-inbox-v2-format(5)>
+inbox to C<N> shards .  Since L<xapian-compact(1)> is not suitable
+for merging, users can rely on this switch to reshard the
 existing Xapian database(s) to any positive value of C<N>.
 
 This is useful in case the Xapian DB was created with too few or
-too many partitions given the capabilities of the current
-hardware.
+too many shards given the capabilities of the current hardware.
 
 =item --blocksize / --no-full / --fuller