[couchdb] branch main updated: Fix typos (#3916)

[va...@apache.org]

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

vatamane pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/couchdb.git


The following commit(s) were added to refs/heads/main by this push:
     new bef7838  Fix typos (#3916)
bef7838 is described below

commit bef78388a4156260c157075bee5bd062fa6cf4bf
Author: Ronny <ro...@kioskkinder.com>
AuthorDate: Sat Jan 29 17:51:18 2022 +0100

    Fix typos (#3916)
    
    Fix typos
---
 COMMITTERS.md |  2 +-
 FDB_NOTES.md  | 17 ++++++++---------
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/COMMITTERS.md b/COMMITTERS.md
index 3b25283..0c9d15e 100644
--- a/COMMITTERS.md
+++ b/COMMITTERS.md
@@ -3,7 +3,7 @@ Apache CouchDB COMMITTERS
 
 Committers are given a binding vote in certain project decisions, as well as
 write access to public project infrastructure. Committers are elected to the
-project in recognition of their committment to Apache CouchDB. We mean this in
+project in recognition of their commitment to Apache CouchDB. We mean this in
 the sense of being loyal to the project and its interests.
 
 A full list of committers elected to the project is available at:
diff --git a/FDB_NOTES.md b/FDB_NOTES.md
index c0cdc8c..1380ea5 100644
--- a/FDB_NOTES.md
+++ b/FDB_NOTES.md
@@ -1,7 +1,6 @@
 Things of Note
 ===
 
-
 1. If a replication sends us two revisions A and B where one is an
    ancestor of the other, we likely have divergent behavior. However,
    this should never happen In Theory.
@@ -10,12 +9,12 @@ Things of Note
    just happen to be in the same update batch in non-fdb CouchDB)
    we likely have subtly different behavior.
 
-3. I'm relying on repeated reads in an fdb transaction to be "cheap"
+3. I'm relying on repeated reads in a fdb transaction to be "cheap"
    in that the reads would be cached in the fdb_transaction object.
    This needs to be checked for certainty but that appeared to
    be how things behaved in testing.
 
-4. When attempting to create a doc from scratch in an interacitve_edit
+4. When attempting to create a doc from scratch in an interactive_edit
    update, with revisions specified *and* attachment stubs, the reported
    error is now a conflict. Previously the missing_stubs error was
    raised earlier.
@@ -25,7 +24,7 @@ Things of Note
    this situation we don't run the prep_and_validate code on pre-fdb
    CouchDB. The new code always checks stubs before merging revision trees.
    I'm sure the old way would fail somehow, but it would fail further on
-   which means we may have failed with a different reason (conflict, etc)
+   which means we may have failed with a different reason (conflict, etc.)
    before we got to the next place we check for missing stubs.
 
 6. For multi-doc updates we'll need to investigate user versions on
@@ -37,13 +36,13 @@ Things of Note
    key/value approach.
 
 8. We'll want to look at how we currently apply open options to individual
-    elements of an open_revs call. Might turn out that we have to grab a
-    full FDI even if we could look up a rev directly. (i.e., revs_info
-    would require us having the entire FDI, however it'd be wasteful to return
-    all of that in an open_revs call, but bug compatibility ftw!)
+   elements of an open_revs call. Might turn out that we have to grab a
+   full FDI even if we could look up a rev directly. (i.e., revs_info
+   would require us having the entire FDI, however it'd be wasteful to return
+   all of that in an open_revs call, but bug compatibility ftw!)
 
 9. Is it possible that a server_admin can delete a db without being able
-    to open it? If so that's probably changed behavior.
+   to open it? If so that's probably changed behavior.
 
 10. All docs on large active databases might be a thing getting the doc
     count. If we allow range requests up to 5s, and we continue to return