svn commit: r1507243 - in /jackrabbit/oak/trunk/oak-doc/src/site/markdown: construct.md mongomk.md segmentmk.md

[md...@apache.org]

Author: mduerig
Date: Fri Jul 26 09:55:06 2013
New Revision: 1507243

URL: http://svn.apache.org/r1507243
Log:
OAK-301: Document Oak
typos

Modified:
    jackrabbit/oak/trunk/oak-doc/src/site/markdown/construct.md
    jackrabbit/oak/trunk/oak-doc/src/site/markdown/mongomk.md
    jackrabbit/oak/trunk/oak-doc/src/site/markdown/segmentmk.md

Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/construct.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/construct.md?rev=1507243&r1=1507242&r2=1507243&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/construct.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/construct.md Fri Jul 26 09:55:06 2013
@@ -19,7 +19,7 @@
 
 Oak comes with a simple mechanism for constructing content repositories
 for use in embedded deployments and test cases. This article describes this
-mechanism. Deployments in managed enviroments like OSGi should use the native
+mechanism. Deployments in managed environments like OSGi should use the native
 construction/configuration mechanism of the environment.
 
 The core class to use is called `Oak` and can be found in the
@@ -62,7 +62,7 @@ instance being used, so you can chain me
 As you can see, constructing a fully featured JCR repository like this
 will require quite a few plugins. To avoid having to specify them all
 whenever constructing a new repository, we also have a class called
-`Jcr` in the `org.apache.jakcrabbit.oak.jcr` package in `oak-jcr`. That
+`Jcr` in the `org.apache.jackrabbit.oak.jcr` package in `oak-jcr`. That
 class works much like the `Oak` class, but it constructs
 `javax.jcr.Repository` instances instead of `ContentRepositories` and
 automatically includes all the plugin components needed for proper JCR

Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/mongomk.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/mongomk.md?rev=1507243&r1=1507242&r2=1507243&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/mongomk.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/mongomk.md Fri Jul 26 09:55:06 2013
@@ -76,7 +76,7 @@ Finally, the `_revisions` sub-document c
 marked with a revision. E.g. the single entry in the above document tells us
 that everything marked with revision `r13f3875b5d1-0-1` is committed and
 therefore valid. In case the change is done in a branch then the value would be the
-base revision. It is only added for thode nodes which happen to be the commit root
+base revision. It is only added for those nodes which happen to be the commit root
 for any give commit.
 
 Adding a property `prop` with value `foo` to the node in a next step will
@@ -252,7 +252,7 @@ Each MongoMK instance connecting to same
 While performing commits there are certain nodes which are modified but do not become part
 of commit. For example when a node under /a/b/c is updated then the `_lastRev` property also
 needs to be updated to the commit revision. Such changes are accumulated and flushed periodically
-through a asynch job.
+through a asynchronous job.
 
 ### Background Reads
 

Modified: jackrabbit/oak/trunk/oak-doc/src/site/markdown/segmentmk.md
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-doc/src/site/markdown/segmentmk.md?rev=1507243&r1=1507242&r2=1507243&view=diff
==============================================================================
--- jackrabbit/oak/trunk/oak-doc/src/site/markdown/segmentmk.md (original)
+++ jackrabbit/oak/trunk/oak-doc/src/site/markdown/segmentmk.md Fri Jul 26 09:55:06 2013
@@ -134,7 +134,7 @@ The hash code of each key is split into 
 size TBD, B ~ 6) and the keys are sorted into 2^B packs based on the
 first B bits. If a pack contains less than 2^B entries, then it is
 stored directly as a list of key-value pairs. Otherwise the keys are
-split into subpacks based on the next B bits of their hash codes.
+split into sub-packs based on the next B bits of their hash codes.
 When all packs are stored, the list of top-level pack references gets
 stored along with the total number of entries in the map.