[couchdb-documentation] branch rfc/001-fdb-revision-model updated: Follow tuple encoding for booleans

[ko...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

kocolosk pushed a commit to branch rfc/001-fdb-revision-model
in repository https://gitbox.apache.org/repos/asf/couchdb-documentation.git


The following commit(s) were added to refs/heads/rfc/001-fdb-revision-model by this push:
     new 2c0e57c  Follow tuple encoding for booleans
2c0e57c is described below

commit 2c0e57c90ae82d724fbb2aaf78b824c2f8983b52
Author: Adam Kocoloski <ko...@apache.org>
AuthorDate: Sun Mar 24 20:13:01 2019 -0400

    Follow tuple encoding for booleans
---
 rfcs/001-fdb-revision-metadata-model.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/rfcs/001-fdb-revision-metadata-model.md b/rfcs/001-fdb-revision-metadata-model.md
index 357629f..b9e4071 100644
--- a/rfcs/001-fdb-revision-metadata-model.md
+++ b/rfcs/001-fdb-revision-metadata-model.md
@@ -63,8 +63,8 @@ while the other edit branches omit the `Sequence` and `BranchCount`:
 
 The individual elements of the key and value are defined as follows:
 - `DocID`: the document ID
-- `NotDeleted`: `\x00` if the leaf of the edit branch is deleted, `\x01`
-  otherwise
+- `NotDeleted`: `\x26` if the leaf of the edit branch is deleted, `\x27`
+  otherwise (following tuple encoding for booleans)
 - `RevPosition`: positive integer encoded using standard tuple layer encoding
   (signed, variable-length, order-preserving)
 - `RevHash`: 16 bytes uniquely identifying this revision
@@ -97,7 +97,7 @@ one will be the winner following that edit, and can assign the extra metadata to
 that branch accordingly.
 
 A writer attempting to delete the winning branch (i.e., setting `NotDeleted` to
-`\x00`) will need to read two contiguous KVs, the one for the winner and the one
+`\x26`) will need to read two contiguous KVs, the one for the winner and the one
 right before it. If the branch before it will be the winner following the
 deletion then we move the storage of the extra metadata to it accordingly. If
 the tombstoned branch remains the winner for this document then we only update