{"action":"created","comment":{"url":"https://api.github.com/repos/ravendb/book/pulls/comments/141273054","pull_request_review_id":65446501,"id":141273054,"diff_hunk":"@@ -592,156 +581,152 @@ using (var session = store.OpenSession())\n }\n ```\n \n-The code in Listing 6.4 will probably sadden you a bit, since no one usually like to pay the taxman. Hoever, it also exposes an issue with\n+The code in Listing 6.4 will probably sadden you a bit since no one usually likes to pay the taxman. However, it also exposes an issue with\n how RavenDB is replicating transactions. In this case, the document `accounts/1234-A` is involved in two separate transactions.\n-Let us assume that we now need to replicate everything from Listing 6.3 and onward (so my transfer of money to you and your payment of \n+Let's assume that we now need to replicate everything from Listing 6.3 onward (meaning my transfer of money to you and your payment of \n taxes). \n \n We'll further assume that we instructed RavenDB to send the data in as small a unit as possible.  When the database instance needs to \n replicate the documents to another instance, it will replicate them on a per transaction basis. Starting from the transaction that was\n-generated for Listing 6.3, we'll replicate `accounts/4321-C` but _not_ `accounts/1234-A`, why is that? \n+generated for Listing 6.3, we'll replicate `accounts/4321-C` but _not_ `accounts/1234-A`. Why is that? \n \n-The `accounts/1234-A` document will not be replicated because it was changed in the transaction for Listing 6.3, but it was also changed\n-by a later transaction (the one from Listing 6.4). Since we replicate just the current state of the documents, and in this case, we \n-configured RavenDB to send the smallest possible batch size, we will replicate just the documents that were modified in Listing 6.3, but\n-not documents that were modified in the transaction for Listing 6.3 and then later modified by another transaction.\n+The `accounts/1234-A` document will not be replicated because, though it was changed in the transaction for Listing 6.3, it \n+was also changed by a later transaction (the one from Listing 6.4). Since we replicate only the current state of the documents \n+and, in this case, we configured RavenDB to send the smallest possible batch size, we'll replicate only the documents that were\n+modified in Listing 6.3&mdash;not documents that were modified in the transaction for Listing 6.3 and then later modified by \n+another transaction.\n \n-This means that we'll first have a batch replicated `accounts/4321-C` document (my transfer of the money) and then another batch with\n-`accounts/1234-A` and `accounts/48879-B` document (your payment to the taxman). A client that will read from another instance may then\n+This means we'll first have a batch-replicated `accounts/4321-C` document (my transfer of the money) and then another batch with the\n+`accounts/1234-A` and `accounts/48879-B` documents (your payment to the taxman). A client reading from another instance may then\n get an invalid state.\n \n-Luckily, everything is not lost. If you need transaction atomicity in a distributed fashion, you can either make sure that the documents\n-you care about are always updated together, this will ensure that they are always part of the same transaction and sent in the same batch.\n-This is possible, but often it is awkward to do. Instead, you can use revisions.\n+Luckily, everything is not lost. If you need transaction atomicity in a distributed fashion, you have a few options. You can make sure that the documents you care about are always updated together. This will ensure that these documents are always part of the same transaction and sent in the same batch. But this is often awkward to do. \n \n-When you enable revisions on a collection, whenever a docuemnt is modified, a revision is written. And it is written as part of the same\n-transaction and it flows across replication in the same indivisible batch as any other operation. When RavenDB gets a revision of a \n-docuemnt that is newer then the document it has, it will update the docuemnt to match the revision. In effect, we'll send the entire \n-transaction in Listing 6.3 as it was, so a client observing a second node can never see a partial transaction.\n+Another option is to use revisions. When you enable revisions on a collection, a revision is written whenever a document is modified. It's written as part of the same\n+transaction, and it flows across replication in the same indivisible batch as any other operation. When RavenDB gets a revision of a \n+document that's newer than the one it has, it will update the document to match the revision. In effect, we'll send the entire \n+transaction in Listing 6.3 as it was so that a client observing a second node can never see a partial transaction.\n \n-As you can see, revisions are a very powerful feature, and they are used in far more scenario then might be initially expected. The idea \n-with relying on revisions to handle transaction consistency is that in many cases, it doesn't matter. A proper document model follows the\n-Isolated, Independent and Coherent tenants, which usually mean that you don't _need_ this feature. But when you do, and it most certainly\n-come up quite often^[It is not something that you'll use for everyting, but in most applications, there is one or two places where it can\n-be _really_ useful.]. The key here is that you aren't paying for tracking all the intermediate values unless you actually need this. \n+As you can see, revisions are a very powerful feature, and they're used in more scenarios than might initially be expected. The idea \n+behind relying on revisions to handle transaction consistency is that, in many cases, it doesn't matter. A proper document model follows the\n+isolated, independent and coherent tenets, which usually means you don't _need_ this feature. But when you do, and it most certainly\n+will come up,^[It's not something you'll use for everything, but in most applications there's one or two places where it can\n+be _really_ useful.] the key here is that you aren't paying for tracking all the intermediate values unless you actually need this. \n \n-A lot of RavenDB features use the \"Pay to Play\" model, where if you aren't using a specific feature, you don't need to pay the performance \n+A lot of RavenDB features use the \"pay to play\" model, meaning if you aren't using a specific feature, you don't need to pay the performance \n cost of supporting it.\n \n #### Change vectors\n \n-In the previous section, I mentioned that when a database instance gets a document revision that is newer than its copy of the document it\n-will update the document to match the revision. This form the basis of ensuring transaction boundary consistency across servers. But that \n-doesn't answer an important question. What does it mean, newer? \n+In the previous section, I mentioned that when a database instance gets a document revision that's newer than its copy of the document, it\n+will update the document to match the revision. This lays the foundation for ensuring transaction boundary consistency across servers. But this \n+doesn't answer an important question: what does \"newer\" even mean? \n \n-The easiest way to answer this is to take a look at the clock. After all, newer means time, and we can just check at what time the revision\n-and the document were modified. That doesn't actually work, however, when running in a distributed sytem. Each machine in the cluster may\n-slightly different idea about the time, and clock drift is a serious problem. Beyond that, concurrency in the cluster may mean that \n-operations have happened in the exact same time or close enough that we can't tell otherwise. \n+The easiest way to answer that question is to take a look at the clock. After all, \"newer\" is a function of time, and we can just check what time the document and revision were modified. But that doesn't actually work when running in a distributed system. Each machine in the cluster may\n+have a slightly different idea about the time, and clock drift is a serious problem. Beyond that, concurrency in the cluster may mean that \n+operations have happened at the exact same time or close enough that we can't tell otherwise. \n \n-This is confusing, and can cause quite a headache in a distributed system. In order to deal with this, RavenDB uses change vectors (they\n-are sometimes also called Vector Clocks) to tell when things hapened. A change vector comprise of the node id and a sequence number (the \n+This is confusing and can cause quite a headache in a distributed system. In order to deal with this, RavenDB uses change vectors (they\n+are sometimes also called vector clocks) to tell when things happened. A change vector is comprised of the node ID and a sequence number (the \n etag). Whenever a modification happens on a database, a change vector will be generated. Here are a few examples of change vectors:\n \n * A:1\n * B:2\n * A:3, B:1\n * A:3, B:3, C:5\n \n-For the purpose of discussion, `A`/`B`/`C` are the node ids and the numbers are the per node sequence number. You can see that with `A:1`\n-and `B:2`, there is no way for us to provide any order. This is because they are local to each node, and there is no dependency between \n+For the purpose of discussion, `A`/`B`/`C` are the node IDs and the numbers are the per-node sequence number. You can see that, with `A:1`\n+and `B:2`, there's no way for us to provide any order. This is because they're local to each node and there's no dependency between \n them. \n-On the other hand, the `A:3, B:1` change vector provide us with more infromation. We know that it came after `A:3` and after `B:1`. Because\n-of this we can tell that it is after `A:1`, but we can't tell whatever it happened before or after `B:2`. On the other hand, it is clear\n+On the other hand, the `A:3, B:1` change vector provides us with more information. We know that it came after `A:3` and after `B:1`. Because\n+of this, we can tell that it's after `A:1`, but we can't tell whether it happened before or after `B:2`. On the other hand, it's clear\n that `A:3, B:3, C:5` happened after everything else.\n-In other words, we use change vector to record the observed state in each node, and we can piece out the timeline from that point onward. \n+In other words, we use change vectors to record the observed state in each node, and we can piece out the timeline from that point onward. \n \n-The different nodes in a database group will try to ensure that each database instance is aware of the last etag on each node, so they can\n-create a coherent timeline across the cluster. This isn't meant to be a 100% solution, but it is a useful optimization for certain operations.\n-Always having the last etag from the nodes also make it easier to reason about concurrency in the cluster. You can see for yourself that when\n-you save a document, it will have a change vector entry from the node you saved it on and also for all the other nodes in the cluster.\n+The different nodes in a database group will try to ensure that each database instance is aware of the last etag on each node so they can\n+create a coherent timeline across the cluster. This isn't meant to be a 100 percent foolproof solution, but it's a useful optimization for certain operations.\n+Always having the last etag from the nodes also makes it easier to reason about concurrency in the cluster. You can see for yourself that when\n+you save a document, it will have a change vector entry from the node you saved it on, as well as for all the other nodes in the cluster.\n \n-Change vectors and how they come into play are pretty hard to grasp just by talking about them, so let us do some practice. We'll create a\n-new database, called \"ChangeVectorTrailRun\" on 2 of the nodes in the cluster. Then go into the database and create a document called `users/1`.\n+Change vectors and how they come into play are pretty hard concepts to grasp just by talking about them, so let's do some practice. We'll create a\n+new database called \"ChangeVectorTrialRun\" on two of the nodes in the cluster. Then we'll go into the database and create a document called `users/1`.\n \n-Change it a few times and observe the `@change-vector` property in the `@metadata`. Even though you have only modified this document on a single\n-node, you can see that the database instance also include the change vector from the other instance as well. You can see this example in Figure\n+Change this a few times, and we can observe the `@change-vector` property in the `@metadata`. Even though we've only modified this document on a single\n+node, you can see that the database instance also includes the change vector from the other instance as well. Take a look at this example in Figure\n 6.11\n \n ![A document change vector in a cluster](./Ch06/img11.png)\n \n Using this change vector, this document was written at or after etag 7 on node `A` and at or after etag 5 on node `B`. We created this document \n-on node `A`, so how can we have a change vector entry for node `B` here? The answer is simple, we know\n-what the etag of node `B` was because it told it that on our last replication batch and we incorporate this information in future change vectors.\n+on node `A`, so how can we have a change vector entry for node `B` here? The answer is simple: we know\n+what the etag of node `B` was because it told us on our last replication batch. We'll incorporate this information in future change vectors.\n \n Change vectors are incredibly important inside RavenDB (and in many other distributed systems) because they allow us to know, without relying\n-on a shared clock, when things have happened. This turns out to be quite useful in many cases. For example, let us assume that a database \n-instance recieve a document via replication, but it already have this document stored.\n+on a shared clock, when things have happened. This turns out to be quite useful in many cases. For example, let's assume that a database \n+instance received a document via replication but already has this document stored.\n \n-How would the database instance know if the document that arrived via replication is an old version of the document, that we should ignore, or\n-if this is a new version, that need to overwrite the existing document? It uses the change vector to tell that. In that way, even if a document\n-if modified on different server each time, we can still now whatever our version is newer or older then the version that we just got via \n+How would the database instance know if the document that arrived via replication is an old version of the document that we should ignore or\n+if it's a new version that needs to overwrite the existing document? The answer is that it uses the change vector to tell. In this way, even if a document\n+is modified on a different server each time, we can still know whether our version is newer or older than the version we just received via \n replication.\n \n-However, newer or older aren't the only options that we have. There is also the option of a conflict update. \n+However, \"newer\" or \"older\" aren't the only options that we have. There is also the option of a conflict update. \n \n #### Conflicts\n \n-A conflict occurs when the same document is updated on two nodes independently from one another. This can happen because of a network split or\n-several client updates that each talked to a different node faster then we can replicate the information. Let us consider the simplest case, we\n-have the document `users/1` whose current change vector is `A:7, B:5` and we modify it on nodes A and B concurrently. \n+A conflict occurs when the same document is updated on two nodes independently of one another. This can happen because of a network split or because of several client updates that each talked to a different node faster than we could replicate the information. \n \n-On the database instance on node `B`, we'll have the change vector `A:8, B:5` and on node B we'll have `A:3, B:8`. In this case, there is no way\n-for us to tell which version of the document is newer then the other. This is a conflict. In a distributed system, you can either choose to run a \n-consensus (which require consulting a majority on every decision) or accept the potential for conflicts. For documents writes, RavenDB chose to \n+Let's consider the simplest case. Say we\n+have the document `users/1` whose current change vector is `A:7, B:5`, and we modify it on nodes A and B concurrently. On the database instance on node `B`, we'll have the change vector `A:8, B:5`, and on node B we'll have `A:3, B:8`. In this case, there's no way\n+for us to tell which version of the document is newer than the other. This is a conflict. In a distributed system, you can either choose to run a \n+consensus (which requires consulting a majority on every decision) or accept the potential for conflicts. For document writes, RavenDB chooses to \n accept conflicts as a tradeoff of always being able to accept writes.\n \n-The question is, how are we going to handle such a case? Let us generate a conflict manually and see how this is handled. Here is how we'll do it:\n+The question is this&mdash;how are we going to handle such a case? Let's generate a conflict manually and see how this is handled. Here's how we'll do it:\n \n-* Kill node `B` (it is running on `127.0.0.2`). You can do that by simply closing the console window that is running it.\n-* Modify the `users/1` document on node `A` so its name property will be: \"John\" and save the document. You can see how this will look like in \n+* Kill node `B`. (It's running on `127.0.0.2`.) You can do that by simply closing the console window that's running it.\n+* Modify the `users/1` document on node `A` so its name property will be \"John,\" and save the document. You can see how this will look in \n   Figure 6.12.\n-* Kill node `A` (it is running on `127.0.0.1`). \n+* Kill node `A`. (It's running on `127.0.0.1`.) \n * Bring up node `B` by executing `start ./Server/Raven.Server.exe ( $cmdLine -f 2 )`.\n-* Modify the `users/1` document on node `B` so its name property will be: \"Doe\" and save the document. You can see how this will look like in\n+* Modify the `users/1` document on node `B` so its name property will be \"Doe,\" and save the document. You can see how this will look in\n   Figure 6.13.\n * Bring up node `A` by executing `start ./Server/Raven.Server.exe ( $cmdLine -f 1 )`.\n \n ![The `users/1` document after modifications on node `B`](./Ch06/img12.png)\n \n ![The `users/1` document after modifications on node `A`](./Ch06/img13.png)\n \n-At this point an interesting thing will take place. If you'll watch the `Users` collection, you'll notice that it is _empty_, and that the \n-`Conflicts` entry in the Studio is showing that there is a conflict. Go to `Documents` in the studio and then to `Conflicts` and you'll see the\n+At this point, an interesting thing will take place. If you watch the `Users` collection, you'll notice that it's _empty_ and that the \n+`Conflicts` entry in the studio is showing there's a conflict. Go to `Documents` in the studio and then to `Conflicts`, and you'll see the\n missing document. \n \n-In fact, you'll see _three_ versions of this document, as you can see in Figure 6.14. For developers, this screen show be very familiar, it is\n-showing a conflict just as you would get in any source control system. You can also resolve it in just the same manner, by deciding what changes\n-to accept and saving. Change the `Name` property to be \"John Doe\" and click on `Save`.\n+In fact, you'll see _three_ versions of this document, as displayed in Figure 6.14. For developers, the screen shown may look very familiar. It's\n+showing a conflict just as you would get in any source control system. You can also resolve it in the same manner: by deciding what changes\n+to accept and saving. Change the `Name` property to be \"John Doe\" and click `Save`.\n \n-![Manual conflict resolution in the Studio](./Ch06/img14.png)\n+![Manual conflict resolution in the studio](./Ch06/img14.png)\n \n-The conflict is now resolved and you can see the document is back in its proper place, the `Users` collection.\n-As you could see, getting to the point where we could reliably generate a conflict was a rather involved process, they aren't something that is\n-expected to happen frequently. At the same time, production systems have a nasty habit of throwing up a _lot_ of hurdles even during normal \n+The conflict is now resolved, and you can see the document is back in its proper place&mdash;the `Users` collection.\n+As you could see, getting to the point where we could reliably generate a conflict was a rather involved process. Conflicts aren't expected to happen frequently. At the same time, production systems have a nasty habit of throwing up a _lot_ of hurdles, even during normal \n operations. Conflicts can and do occur in production systems, especially busy ones.\n \n-It wouldn't be reasonable to expect a manual intervention each and every time that you need to resolve a conflict. Instead, RavenDB has several\n+It wouldn't be reasonable to expect a manual intervention each and every time you need to resolve a conflict. Instead, RavenDB has several\n conflict resolution strategies that you can use:\n \n-* If the documents are identical (same change applied on multiple nodes), they can automatically be merged. This also apply if the document was\n+* If the documents are identical (same change applied on multiple nodes), they can automatically be merged. This also applies if the document was\n   deleted in multiple nodes and we detected a conflict.\n-* You can specify your own conflict resolution behavior by writing JavaScript function that would apply to all the conflicts and prdouce a merged\n+* You can specify your own conflict resolution behavior by writing a JavaScript function that applies to all conflicts and produces a merged\n   output. We'll see an example of that shortly.\n-* You can designate a node whose changes will be considered authoritative and all conflicts will be resolved in its favor.\n-* Finally, you can chose to resolve to the latest version based on wall clock time.\n+* You can designate a node whose changes will be considered authoritative, and all conflicts will be resolved in its favor.\n+* Finally, you can choose to resolve to the latest version based on wall clock time.","path":"Ch06/CH06.md","position":1039,"original_position":1039,"commit_id":"d9b3ccc4a8a0ac5250082cb9b640fabda31b58b9","original_commit_id":"d9b3ccc4a8a0ac5250082cb9b640fabda31b58b9","user":{"login":"ayende","id":116915,"avatar_url":"https://avatars3.githubusercontent.com/u/116915?v=4","gravatar_id":"","url":"https://api.github.com/users/ayende","html_url":"https://github.com/ayende","followers_url":"https://api.github.com/users/ayende/followers","following_url":"https://api.github.com/users/ayende/following{/other_user}","gists_url":"https://api.github.com/users/ayende/gists{/gist_id}","starred_url":"https://api.github.com/users/ayende/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ayende/subscriptions","organizations_url":"https://api.github.com/users/ayende/orgs","repos_url":"https://api.github.com/users/ayende/repos","events_url":"https://api.github.com/users/ayende/events{/privacy}","received_events_url":"https://api.github.com/users/ayende/received_events","type":"User","site_admin":false},"body":"Add TODO for the screenshot for managing this","created_at":"2017-09-27T08:22:34Z","updated_at":"2017-09-27T08:33:44Z","html_url":"https://github.com/ravendb/book/pull/50#discussion_r141273054","pull_request_url":"https://api.github.com/repos/ravendb/book/pulls/50","author_association":"OWNER","_links":{"self":{"href":"https://api.github.com/repos/ravendb/book/pulls/comments/141273054"},"html":{"href":"https://github.com/ravendb/book/pull/50#discussion_r141273054"},"pull_request":{"href":"https://api.github.com/repos/ravendb/book/pulls/50"}}},"pull_request":{"url":"https://api.github.com/repos/ravendb/book/pulls/50","id":141967372,"html_url":"https://github.com/ravendb/book/pull/50","diff_url":"https://github.com/ravendb/book/pull/50.diff","patch_url":"https://github.com/ravendb/book/pull/50.patch","issue_url":"https://api.github.com/repos/ravendb/book/issues/50","number":50,"state":"open","locked":false,"title":"Chapter 6 Review","user":{"login":"amandamuledy","id":29898019,"avatar_url":"https://avatars0.githubusercontent.com/u/29898019?v=4","gravatar_id":"","url":"https://api.github.com/users/amandamuledy","html_url":"https://github.com/amandamuledy","followers_url":"https://api.github.com/users/amandamuledy/followers","following_url":"https://api.github.com/users/amandamuledy/following{/other_user}","gists_url":"https://api.github.com/users/amandamuledy/gists{/gist_id}","starred_url":"https://api.github.com/users/amandamuledy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amandamuledy/subscriptions","organizations_url":"https://api.github.com/users/amandamuledy/orgs","repos_url":"https://api.github.com/users/amandamuledy/repos","events_url":"https://api.github.com/users/amandamuledy/events{/privacy}","received_events_url":"https://api.github.com/users/amandamuledy/received_events","type":"User","site_admin":false},"body":"Here are my comments. Erik has some, too, from his review.\r\n\r\nLine 137: Please check my changes here to make sure I didn't hurt your meaning. The phrasing was a little awkward, and this would be a more natural way of saying it if I'm interpreting you correctly.\r\n\r\nLine 176: You might want to remind the reader why they're doing this. You haven't issued any instructions in a while, so this is a little bit abrupt. It's also not quite clear what the goal of these instructions are. Maybe introduce the sentence with \"In order to ______, you would click the…\"\r\n\r\nLine 184: I changed this because I felt it wasn't coming off the way you intended it to (the word \"beat,\" used in this way, will have connotations you don't want)\r\n\r\nLine 381: Switching from \"you\" to \"we\" is confusing here. I would have changed it, but I'm not actually sure who \"we\" is supposed to be in this case.\r\n\r\nLine 556: I think you should define who \"we\" is here.\r\n\r\nLine 175: Throughout this chapter, you switch off capitalizing \"Node A\" and \"Node B\" and de-capitalizing it. I suggest picking one and unifying the treatment in this chapter.","created_at":"2017-09-19T22:02:10Z","updated_at":"2017-09-27T08:33:44Z","closed_at":null,"merged_at":null,"merge_commit_sha":"e672526ae0502cabe7e343e5115b1a93cfb4a5a2","assignee":null,"assignees":[],"requested_reviewers":[],"milestone":null,"commits_url":"https://api.github.com/repos/ravendb/book/pulls/50/commits","review_comments_url":"https://api.github.com/repos/ravendb/book/pulls/50/comments","review_comment_url":"https://api.github.com/repos/ravendb/book/pulls/comments{/number}","comments_url":"https://api.github.com/repos/ravendb/book/issues/50/comments","statuses_url":"https://api.github.com/repos/ravendb/book/statuses/d9b3ccc4a8a0ac5250082cb9b640fabda31b58b9","head":{"label":"amandamuledy:v4.0","ref":"v4.0","sha":"d9b3ccc4a8a0ac5250082cb9b640fabda31b58b9","user":{"login":"amandamuledy","id":29898019,"avatar_url":"https://avatars0.githubusercontent.com/u/29898019?v=4","gravatar_id":"","url":"https://api.github.com/users/amandamuledy","html_url":"https://github.com/amandamuledy","followers_url":"https://api.github.com/users/amandamuledy/followers","following_url":"https://api.github.com/users/amandamuledy/following{/other_user}","gists_url":"https://api.github.com/users/amandamuledy/gists{/gist_id}","starred_url":"https://api.github.com/users/amandamuledy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amandamuledy/subscriptions","organizations_url":"https://api.github.com/users/amandamuledy/orgs","repos_url":"https://api.github.com/users/amandamuledy/repos","events_url":"https://api.github.com/users/amandamuledy/events{/privacy}","received_events_url":"https://api.github.com/users/amandamuledy/received_events","type":"User","site_admin":false},"repo":{"id":96238432,"name":"book","full_name":"amandamuledy/book","owner":{"login":"amandamuledy","id":29898019,"avatar_url":"https://avatars0.githubusercontent.com/u/29898019?v=4","gravatar_id":"","url":"https://api.github.com/users/amandamuledy","html_url":"https://github.com/amandamuledy","followers_url":"https://api.github.com/users/amandamuledy/followers","following_url":"https://api.github.com/users/amandamuledy/following{/other_user}","gists_url":"https://api.github.com/users/amandamuledy/gists{/gist_id}","starred_url":"https://api.github.com/users/amandamuledy/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/amandamuledy/subscriptions","organizations_url":"https://api.github.com/users/amandamuledy/orgs","repos_url":"https://api.github.com/users/amandamuledy/repos","events_url":"https://api.github.com/users/amandamuledy/events{/privacy}","received_events_url":"https://api.github.com/users/amandamuledy/received_events","type":"User","site_admin":false},"private":false,"html_url":"https://github.com/amandamuledy/book","description":"RavenDB Book","fork":true,"url":"https://api.github.com/repos/amandamuledy/book","forks_url":"https://api.github.com/repos/amandamuledy/book/forks","keys_url":"https://api.github.com/repos/amandamuledy/book/keys{/key_id}","collaborators_url":"https://api.github.com/repos/amandamuledy/book/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/amandamuledy/book/teams","hooks_url":"https://api.github.com/repos/amandamuledy/book/hooks","issue_events_url":"https://api.github.com/repos/amandamuledy/book/issues/events{/number}","events_url":"https://api.github.com/repos/amandamuledy/book/events","assignees_url":"https://api.github.com/repos/amandamuledy/book/assignees{/user}","branches_url":"https://api.github.com/repos/amandamuledy/book/branches{/branch}","tags_url":"https://api.github.com/repos/amandamuledy/book/tags","blobs_url":"https://api.github.com/repos/amandamuledy/book/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/amandamuledy/book/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/amandamuledy/book/git/refs{/sha}","trees_url":"https://api.github.com/repos/amandamuledy/book/git/trees{/sha}","statuses_url":"https://api.github.com/repos/amandamuledy/book/statuses/{sha}","languages_url":"https://api.github.com/repos/amandamuledy/book/languages","stargazers_url":"https://api.github.com/repos/amandamuledy/book/stargazers","contributors_url":"https://api.github.com/repos/amandamuledy/book/contributors","subscribers_url":"https://api.github.com/repos/amandamuledy/book/subscribers","subscription_url":"https://api.github.com/repos/amandamuledy/book/subscription","commits_url":"https://api.github.com/repos/amandamuledy/book/commits{/sha}","git_commits_url":"https://api.github.com/repos/amandamuledy/book/git/commits{/sha}","comments_url":"https://api.github.com/repos/amandamuledy/book/comments{/number}","issue_comment_url":"https://api.github.com/repos/amandamuledy/book/issues/comments{/number}","contents_url":"https://api.github.com/repos/amandamuledy/book/contents/{+path}","compare_url":"https://api.github.com/repos/amandamuledy/book/compare/{base}...{head}","merges_url":"https://api.github.com/repos/amandamuledy/book/merges","archive_url":"https://api.github.com/repos/amandamuledy/book/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/amandamuledy/book/downloads","issues_url":"https://api.github.com/repos/amandamuledy/book/issues{/number}","pulls_url":"https://api.github.com/repos/amandamuledy/book/pulls{/number}","milestones_url":"https://api.github.com/repos/amandamuledy/book/milestones{/number}","notifications_url":"https://api.github.com/repos/amandamuledy/book/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/amandamuledy/book/labels{/name}","releases_url":"https://api.github.com/repos/amandamuledy/book/releases{/id}","deployments_url":"https://api.github.com/repos/amandamuledy/book/deployments","created_at":"2017-07-04T16:56:34Z","updated_at":"2017-07-04T16:56:36Z","pushed_at":"2017-09-19T01:49:00Z","git_url":"git://github.com/amandamuledy/book.git","ssh_url":"git@github.com:amandamuledy/book.git","clone_url":"https://github.com/amandamuledy/book.git","svn_url":"https://github.com/amandamuledy/book","homepage":"","size":13881,"stargazers_count":0,"watchers_count":0,"language":"PowerShell","has_issues":false,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":0,"mirror_url":null,"open_issues_count":0,"forks":0,"open_issues":0,"watchers":0,"default_branch":"v4.0"}},"base":{"label":"ravendb:v4.0","ref":"v4.0","sha":"1cd4393c18af8214ae404dc89ef4b31161c85250","user":{"login":"ravendb","id":213792,"avatar_url":"https://avatars0.githubusercontent.com/u/213792?v=4","gravatar_id":"","url":"https://api.github.com/users/ravendb","html_url":"https://github.com/ravendb","followers_url":"https://api.github.com/users/ravendb/followers","following_url":"https://api.github.com/users/ravendb/following{/other_user}","gists_url":"https://api.github.com/users/ravendb/gists{/gist_id}","starred_url":"https://api.github.com/users/ravendb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ravendb/subscriptions","organizations_url":"https://api.github.com/users/ravendb/orgs","repos_url":"https://api.github.com/users/ravendb/repos","events_url":"https://api.github.com/users/ravendb/events{/privacy}","received_events_url":"https://api.github.com/users/ravendb/received_events","type":"Organization","site_admin":false},"repo":{"id":22052180,"name":"book","full_name":"ravendb/book","owner":{"login":"ravendb","id":213792,"avatar_url":"https://avatars0.githubusercontent.com/u/213792?v=4","gravatar_id":"","url":"https://api.github.com/users/ravendb","html_url":"https://github.com/ravendb","followers_url":"https://api.github.com/users/ravendb/followers","following_url":"https://api.github.com/users/ravendb/following{/other_user}","gists_url":"https://api.github.com/users/ravendb/gists{/gist_id}","starred_url":"https://api.github.com/users/ravendb/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ravendb/subscriptions","organizations_url":"https://api.github.com/users/ravendb/orgs","repos_url":"https://api.github.com/users/ravendb/repos","events_url":"https://api.github.com/users/ravendb/events{/privacy}","received_events_url":"https://api.github.com/users/ravendb/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/ravendb/book","description":"RavenDB Book","fork":false,"url":"https://api.github.com/repos/ravendb/book","forks_url":"https://api.github.com/repos/ravendb/book/forks","keys_url":"https://api.github.com/repos/ravendb/book/keys{/key_id}","collaborators_url":"https://api.github.com/repos/ravendb/book/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/ravendb/book/teams","hooks_url":"https://api.github.com/repos/ravendb/book/hooks","issue_events_url":"https://api.github.com/repos/ravendb/book/issues/events{/number}","events_url":"https://api.github.com/repos/ravendb/book/events","assignees_url":"https://api.github.com/repos/ravendb/book/assignees{/user}","branches_url":"https://api.github.com/repos/ravendb/book/branches{/branch}","tags_url":"https://api.github.com/repos/ravendb/book/tags","blobs_url":"https://api.github.com/repos/ravendb/book/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/ravendb/book/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/ravendb/book/git/refs{/sha}","trees_url":"https://api.github.com/repos/ravendb/book/git/trees{/sha}","statuses_url":"https://api.github.com/repos/ravendb/book/statuses/{sha}","languages_url":"https://api.github.com/repos/ravendb/book/languages","stargazers_url":"https://api.github.com/repos/ravendb/book/stargazers","contributors_url":"https://api.github.com/repos/ravendb/book/contributors","subscribers_url":"https://api.github.com/repos/ravendb/book/subscribers","subscription_url":"https://api.github.com/repos/ravendb/book/subscription","commits_url":"https://api.github.com/repos/ravendb/book/commits{/sha}","git_commits_url":"https://api.github.com/repos/ravendb/book/git/commits{/sha}","comments_url":"https://api.github.com/repos/ravendb/book/comments{/number}","issue_comment_url":"https://api.github.com/repos/ravendb/book/issues/comments{/number}","contents_url":"https://api.github.com/repos/ravendb/book/contents/{+path}","compare_url":"https://api.github.com/repos/ravendb/book/compare/{base}...{head}","merges_url":"https://api.github.com/repos/ravendb/book/merges","archive_url":"https://api.github.com/repos/ravendb/book/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/ravendb/book/downloads","issues_url":"https://api.github.com/repos/ravendb/book/issues{/number}","pulls_url":"https://api.github.com/repos/ravendb/book/pulls{/number}","milestones_url":"https://api.github.com/repos/ravendb/book/milestones{/number}","notifications_url":"https://api.github.com/repos/ravendb/book/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/ravendb/book/labels{/name}","releases_url":"https://api.github.com/repos/ravendb/book/releases{/id}","deployments_url":"https://api.github.com/repos/ravendb/book/deployments","created_at":"2014-07-21T04:56:36Z","updated_at":"2017-09-05T21:24:54Z","pushed_at":"2017-09-19T22:02:11Z","git_url":"git://github.com/ravendb/book.git","ssh_url":"git@github.com:ravendb/book.git","clone_url":"https://github.com/ravendb/book.git","svn_url":"https://github.com/ravendb/book","homepage":"","size":14039,"stargazers_count":85,"watchers_count":85,"language":"PowerShell","has_issues":true,"has_projects":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":26,"mirror_url":null,"open_issues_count":1,"forks":26,"open_issues":1,"watchers":85,"default_branch":"v4.0"}},"_links":{"self":{"href":"https://api.github.com/repos/ravendb/book/pulls/50"},"html":{"href":"https://github.com/ravendb/book/pull/50"},"issue":{"href":"https://api.github.com/repos/ravendb/book/issues/50"},"comments":{"href":"https://api.github.com/repos/ravendb/book/issues/50/comments"},"review_comments":{"href":"https://api.github.com/repos/ravendb/book/pulls/50/comments"},"review_comment":{"href":"https://api.github.com/repos/ravendb/book/pulls/comments{/number}"},"commits":{"href":"https://api.github.com/repos/ravendb/book/pulls/50/commits"},"statuses":{"href":"https://api.github.com/repos/ravendb/book/statuses/d9b3ccc4a8a0ac5250082cb9b640fabda31b58b9"}},"author_association":"CONTRIBUTOR"}}
{"actor":{"display_login":"ayende"}}