Fixing Typos

version_1/docs/Intro/basic-concepts.markdown

@@ -4,7 +4,7 @@ RavenDB is a database technology based on a client-server architecture. That is
 
 Requests to the server are made using the [Client API](../client-api) available to any .NET or Silverlight application, or by [directly accessing the server's RESTful API](../http-api).
 
-If you are a .NET developer, using the Client API is the easiest way for you to work with RavenDB, as it provides a great amount of features and a very slick API. The RESTful API makes RavenDB accessible from other platforms like AJAX queries in webpages or non-Windows applications written in Ruby-on-Rails, for example.
+If you are a .NET developer, using the Client API is the easiest way for you to work with RavenDB, as it provides a great amount of features and a very slick API. The RESTful API makes RavenDB accessible from other platforms like AJAX queries in web pages or non-Windows applications written in Ruby-on-Rails, for example.
 
 ## The RavenDB server
 
@@ -46,7 +46,7 @@ A _Collection_ is a set of Documents sharing the same RavenDB entity type. It is
 
 With RavenDB each document has its own unique global ID, in the sense that if one was trying to store two different entities under the same id (`users/1` for example) - the second write will overwrite the first one without any warning.
 
-The convention in RavenDB is to have a document ID that is combined of the collection name and the entity's uniqe id within the collection, i.e. `users/1`. However, that is only a convention: document IDs are independent of the entity type, and therefore don't have to contain the name of the collection they are assigned to.
+The convention in RavenDB is to have a document ID that is combined of the collection name and the entity's unique id within the collection, i.e. `users/1`. However, that is only a convention: document IDs are independent of the entity type, and therefore don't have to contain the name of the collection they are assigned to.
 
 ## The Management Studio
 

version_1/docs/Intro/building-from-source.markdown

@@ -2,7 +2,7 @@
 
 RavenDB requires .NET 4.0 SDK installed to build. You should be able to just open RavenDB in Visual Studio 2010 and start working with it immediately.
 
-RavenDB uses PowerShell to execute its build process. Open a PowerShell prompt as a user with Administrator priviliges, and execute:
+RavenDB uses PowerShell to execute its build process. Open a PowerShell prompt as a user with Administrator privileges, and execute:
 
     .\psake.ps1
 

version_1/docs/Theory/index.markdown

@@ -1,5 +1,5 @@
 # Theory
 
-In the Theory section we will explore the land of NoSQL in general, and focus particulary on Document Databases and the various design decisions behind RavenDB - those things that make it so special.
+In the Theory section we will explore the land of NoSQL in general, and focus particularly on Document Databases and the various design decisions behind RavenDB - those things that make it so special.
 
 We will also learn how to correctly design a data model that will enable you to take advantage of RavenDB's power in full.

version_1/docs/Theory/what-is-raven.markdown

@@ -2,7 +2,7 @@
 Raven is a .NET Linq enabled Document Database, focused on providing high performance, schema-less, flexible and scalable NoSQL data store for the .NET and Windows platforms.
 
 ## What does this mean?
-Unlike a traditional RDMBS, Raven doesn't store data in rows and columns, instead allowing you to store any JSON document inside the database. Raven is schema-less, which means that you don't have to pre-define how the documents that are stored in the database will be formed. Because the data is not limited to simply columns and rows, you can store arbitrarily complex data such as arrays, dictionaries and trees with ease.
+Unlike a traditional RDMBS, Raven doesn't store data in rows and columns, instead allowing you to store any JSON document inside the database. Raven is schema-less, which means that you don't have to predefine how the documents that are stored in the database will be formed. Because the data is not limited to simply columns and rows, you can store arbitrarily complex data such as arrays, dictionaries and trees with ease.
 
 On top of the documents, you can define indexes (using C#'s Linq syntax) that the database will maintain for you. This gives you the best of both worlds, you get a schema free nature (no upfront agonizing about the database schema or trying to shoehorn data into a relational model) but you are still able to perform efficient queries.
 

version_1/docs/client-api/advanced/databasecommands/batch.markdown

@@ -36,7 +36,7 @@ Batching PUT and DELETEs:
     					});
     			 }
 
-Defer opration: 
+Defer operation: 
 In RavenDB when you call SaveChanges() all the changed document are batched into one call to the server and either they all pass or non will pass.  
 With the defer command we can add our own commands to this call:
 
@@ -79,7 +79,7 @@ Another operation supported by batching is the [PATCH command](../../partial-doc
 
 ## Concurrency
 
-If an etag is specified in the command, that etag is compared to the current etag on the document on the server. If the etags do no match, a 409 Conlict status code will be returned from the server, causing a ConcurrencyException to be thrown. In such a case, the entire operation fails and non of the updates that were tried will succeed.
+If an etag is specified in the command, that etag is compared to the current etag on the document on the server. If the etags do no match, a 409 Conflict status code will be returned from the server, causing a ConcurrencyException to be thrown. In such a case, the entire operation fails and non of the updates that were tried will succeed.
 
 ## Transactions
 

version_1/docs/client-api/advanced/databasecommands/index.markdown

@@ -57,7 +57,7 @@ A `DatabaseCommands` object is available from both the session object _and_ the
     string PutIndex<TDocument, TReduceResult>(string name, IndexDefinitionBuilder<TDocument, TReduceResult> indexDef);
     string PutIndex<TDocument, TReduceResult>(string name, IndexDefinitionBuilder<TDocument, TReduceResult> indexDef, bool overwrite);
 
-    // Queries the specified index in the Raven flavoured Lucene query syntax
+    // Queries the specified index in the Raven flavored Lucene query syntax
     QueryResult Query(string index, IndexQuery query, string[] includes);
 
     // Deletes the specified index
@@ -131,7 +131,7 @@ A `DatabaseCommands` object is available from both the session object _and_ the
     // Disable all caching within the given scope
     IDisposable DisableAllCaching();
 
-    // Perform a single POST requst containing multiple nested GET requests
+    // Perform a single POST request containing multiple nested GET requests
     GetResponse[] MultiGet(GetRequest[] requests);
 
     // Gets or sets the operations headers

version_1/docs/client-api/advanced/index-administration.markdown

@@ -1,6 +1,6 @@
 # Index administration
 
-RavenDB indices can be administrated easily from the consumer end using either code or the embedded user interface.
+RavenDB indexes can be administrated easily from the consumer end using either code or the embedded user interface.
 
 ## Resetting an index
 

version_1/docs/client-api/basic-operations/saving-new-document.markdown

@@ -94,7 +94,7 @@ Numeric or Guid Id properties are supported and will work seamlessly. In this ca
 
 Using this approach, IDs are available immediately after calling `Store` on the object - the RavenDB session will set a unique ID in memory without asking one from the server.
 
-RavenDB also supports the notion of Identity, for example if you need IDs to be consecutive. By creating a string `Id` property in your entity, and setting it to a value ending with a slash (/), you can tell RavenDB to use that as a key perfix for your entity. That prefix followed by the next available integer ID for it will be your entity's ID _after_ you call `SaveChanges()`.
+RavenDB also supports the notion of Identity, for example if you need IDs to be consecutive. By creating a string `Id` property in your entity, and setting it to a value ending with a slash (/), you can tell RavenDB to use that as a key prefix for your entity. That prefix followed by the next available integer ID for it will be your entity's ID _after_ you call `SaveChanges()`.
 
 You can also assign an ID manually by explicitly setting the string `Id` property of your object, but then if a document already exists in your RavenDB server under the same key it will be overwritten without any warning.
 

version_1/docs/client-api/basic-operations/understanding-session-object.markdown

@@ -29,4 +29,4 @@ By default, RavenDB will not allow operations that might compromise the stabilit
 
 The first one is obvious - unbounded result sets are dangerous, and have been the cause of many failures in RDBMS based systems - unless a result-size has been specified, RavenDB will automatically limit the size of the returned result set.
 
-The second example is less immediate, and should never be reached if RavenDB is being utilised correctly - remote calls are expensive, and the number of remote calls per "session" should be as close to "1" as possible. If the limit is reached, it is a sure sign of either a Select N+1 problem or other mis-use of the RavenDB session.
+The second example is less immediate, and should never be reached if RavenDB is being utilized correctly - remote calls are expensive, and the number of remote calls per "session" should be as close to "1" as possible. If the limit is reached, it is a sure sign of either a Select N+1 problem or other mis-use of the RavenDB session.

version_1/docs/client-api/connecting-to-a-ravendb-datastore.markdown

@@ -87,7 +87,7 @@ The following are samples of a few RavenDB connection strings:
 * Url=http://ravendb.mydomain.com - connect to a remote RavenDB instance at ravendb.mydomain.com, to the default database
 * Url=http://ravendb.mydomain.com;Database=Northwind - connect to a remote RavenDB instance at ravendb.mydomain.com, to the Northwind database there
 * Url=http://ravendb.mydomain.com;User=user;Password=secret- connect to a remote RavenDB instance at ravendb.mydomain.com, with the specified credentials
-* DataDir=~\App_Data\RavenDB;Enslist=False - use embedded mode with the datbase located in the App_Data\RavenDB folder, without DTC support.
+* DataDir=~\App_Data\RavenDB;Enlist=False - use embedded mode with the database located in the App_Data\RavenDB folder, without DTC support.
 
 ## Configuration
 

version_1/docs/client-api/fsharp.markdown

@@ -6,9 +6,9 @@ This documentation assumes some familiarity with the basics of RavenDB.
 
 ## Creating a Document Store
 
-the F# language, contains a type called Discriminated Unions / Algebraic Data Types. By default the JSON.net serialiser that RavenDB uses cannot (de)serialise these types. 
+the F# language, contains a type called Discriminated Unions / Algebraic Data Types. By default the JSON.net serializer that RavenDB uses cannot (de)serialize these types. 
 
-The Raven DB F# client library comes with a JSON.net converter that allows these types to be handled. But we need to customise the document store. This can be acheived by adding the following code. 
+The Raven DB F# client library comes with a JSON.net converter that allows these types to be handled. But we need to customize the document store. This can be achieved by adding the following code. 
 
 	store.Conventions.CustomizeJsonSerializer <- (fun s -> s.Converters.Add(new UnionTypeConverter()))
 
@@ -102,7 +102,7 @@ as you can see this query will return you a tuple of order & customer.
 
 Due to the functional nature of the API we have the ability to compose queries.
 
-For example lets say we wanted all of the customers born on a certain date and all of the orders palaced on that same date. We can define the following
+For example lets say we wanted all of the customers born on a certain date and all of the orders placed on that same date. We can define the following
 
 	let ordersOn (date : DateTime) = 
 		raven { 

version_1/docs/client-api/index.markdown

@@ -1,6 +1,6 @@
 # .NET Client API
 
-So far we have spoken in abstracts, about NoSQL in general and RavenDB in particular. In this chapter we focus on the .NET Client API. We will go through all the steps required to perform basic CRUD operations using RavenDB, familizaring ourselves with RavenDB APIs, concepts and workings.
+So far we have spoken in abstracts, about NoSQL in general and RavenDB in particular. In this chapter we focus on the .NET Client API. We will go through all the steps required to perform basic CRUD operations using RavenDB, familiarizing ourselves with RavenDB APIs, concepts and workings.
 
 ## What is the .NET Client API?
 

version_1/docs/client-api/partial-document-updates.markdown

@@ -65,8 +65,8 @@ Any collection in your entity will be serialized into an array in the resulting
 Being a JSON object, you can treat the entire array as value like shown above. Sometimes, however, you want to access certain items in the array
 
 ## Working with nested operations
-The nested operatoions are only valid of the 'Type' is `PatchCommandType.Modify`.  
-If we want to change all items in a collection we could do that by setting the AllPositions porparty to 'true'
+The nested operations are only valid of the 'Type' is `PatchCommandType.Modify`.  
+If we want to change all items in a collection we could do that by setting the AllPositions property to 'true'
 
 **Here are a few examples of nested operations:**
 

version_1/docs/client-api/querying/handling-document-relationships.markdown

@@ -45,7 +45,7 @@ If we know that whenever we load an `Order` from the database we will need to kn
 
 There wouldn’t be a direct reference between the `Order` and the `Customer`. Instead, `Order` holds a `DenormalizedCustomer`, which contains the interesting bits from `Customer` that we need whenever we process `Order` objects.
 
-But, what happens when the user's address is changed? We will have to perform an aggregate operation to update all orders this customer has made. And what if the customer has a lot of orders or changes their address frequently? Keeping these details in synch could become very demanding on the server. What if another process that works with orders needs a different set of customer properties? The `DenormalizedCustomer` will need to be expanded, possibly to the point that the majority of the customer record is cloned.
+But, what happens when the user's address is changed? We will have to perform an aggregate operation to update all orders this customer has made. And what if the customer has a lot of orders or changes their address frequently? Keeping these details in sync could become very demanding on the server. What if another process that works with orders needs a different set of customer properties? The `DenormalizedCustomer` will need to be expanded, possibly to the point that the majority of the customer record is cloned.
 
 Denormalization is a viable solution for rarely changing data, or for data that must remain the same despite the underlying referenced data changing over time.
 

version_1/docs/client-api/querying/index.markdown

@@ -12,7 +12,7 @@ Therefore, there are 2 types of indexes in RavenDB:
 
 * *Static indexes* are named indexes which are created explicitly by the user.
 
-* *Dynamic indexes* are created by RavenDB automatically following some user query, if no matching index to query was found. RavenDB will find an appropriate index to query, and create it on the fly if one does not already exist. RavenDB will optimize itself based on the actual requests coming in, and can decide to promote a temporary index to a permenant one.
+* *Dynamic indexes* are created by RavenDB automatically following some user query, if no matching index to query was found. RavenDB will find an appropriate index to query, and create it on the fly if one does not already exist. RavenDB will optimize itself based on the actual requests coming in, and can decide to promote a temporary index to a permanent one.
 
 Also worth mentioning at this stage is the notion of *stale indexes*. Because RavenDB follows the "better stale than offline" approach, querying an index may return stale results - for example when a user queries a database that while a mass-update in progress. RavenDB will let the user know if results are stale, and can also be told to wait until non-stale results are available.
 

version_1/docs/client-api/querying/stale-indexes.markdown

@@ -32,9 +32,9 @@ Even when using `WaitForNonStaleResults` with a time-out like shown above, it is
 
 This will make sure that you get the latest results up to that point in time. All pending tasks for changes occurred after this cut-off point will not be considered. And like before, a time-out can be set on that as well.
 
-`WaitForNonStaleResultsAsOfNow` is also available, which is equivallent of calling `WaitForNonStaleResultsAsOf(DateTime.Now)`.
+`WaitForNonStaleResultsAsOfNow` is also available, which is equivalent of calling `WaitForNonStaleResultsAsOf(DateTime.Now)`.
 
-Another option is to use `WaitForNonStaleResultsAsOfLastWrite`, which does exactly what it says it do. It tracks the last write by the application, and uses that as the cutoff point. This is usually recommended if you are working on machines where clock syncronization might be an issue, since `WaitForNonStaleResultsAsOfLastWrite` doesn't use the machine time, it uses the etag values for the writes.
+Another option is to use `WaitForNonStaleResultsAsOfLastWrite`, which does exactly what it says it do. It tracks the last write by the application, and uses that as the cutoff point. This is usually recommended if you are working on machines where clock synchronization might be an issue, since `WaitForNonStaleResultsAsOfLastWrite` doesn't use the machine time, it uses the etag values for the writes.
 
 You can also setup the document store to always wait for the last write, like so:
 

version_1/docs/client-api/querying/static-indexes/configuring-index-options.markdown

@@ -4,7 +4,7 @@ The indexes each RavenDB server instance uses to facilitate fast queries are pow
 
 Lucene takes a _Document_ , breaks it down into _Fields_ , and then split all text in a _Field_ into  tokens ( _Terms_ ) in a process called _Tokenization_ . Those tokens are what will be stored in the index, and be later searched upon.
 
-After a successful indexing operation, RavenDB feeds Lucene with each entity from the results as a _Document_ , and marks every property in it as a _Field_ . Then every property is going through the _Tokenization_ process using an object called a "Lucene Analyzer", and then finaly is stored into the index.
+After a successful indexing operation, RavenDB feeds Lucene with each entity from the results as a _Document_ , and marks every property in it as a _Field_ . Then every property is going through the _Tokenization_ process using an object called a "Lucene Analyzer", and then finally is stored into the index.
 
 This process and its results can be controlled by using various field options and Analyzers, as explained below.
 

version_1/docs/client-api/querying/static-indexes/indexing-hierarchies.markdown

@@ -21,7 +21,7 @@ One of the greatest advantages of a document database is that we have very few l
 
 While it is very easy to work with such a document in all respect, it does bring up an interesting question, how can we index all comments in the post?
 
-The answer to that is that Raven contains builtin support for indexing hierarchies, we can define an index using the following syntax:
+The answer to that is that Raven contains built-in support for indexing hierarchies, we can define an index using the following syntax:
 
     from post in docs.Posts
     from comment in Hierarchy(post, "Comments") 

version_1/docs/client-api/querying/using-linq-to-query-ravendb.markdown

@@ -46,7 +46,7 @@ Here is how to use projections:
 
 {CODE linquerying_5@Consumer\DynamicQueries.cs /}
 
-Projections are useful when only part of the data is needed for your operation. Whenever change tracking isn't required, you're advised to consider using projections to ease bandwidth traffic between you and the server. This isn't a general rule, because caching in the entire application also plays an important role here, and it might make it more efficent to load the cache results of a query than to issue a remote query for a projection.
+Projections are useful when only part of the data is needed for your operation. Whenever change tracking isn't required, you're advised to consider using projections to ease bandwidth traffic between you and the server. This isn't a general rule, because caching in the entire application also plays an important role here, and it might make it more efficient to load the cache results of a query than to issue a remote query for a projection.
 You can also use the `Distinct` method to only return distinct results from the server. When using projections, that means that on the server side, the database will compare all the projected fields for each object, and send us only unique results. If you aren't using projections, this has no effect but causing the server to do more work.
 
 ## Sorting