Git client SVN

book/09-git-and-other-scms/sections/client-svn.asc

@@ -102,7 +102,7 @@ Checked out HEAD:
 
 This runs the equivalent of two commands – `git svn init` followed by `git svn fetch` – on the URL you provide.
 This can take a while.
-The test project has only about 75 commits and the codebase isn't that big, but Git has to check out each version, one at a time, and commit it individually.
+If, for example, the test project has only about 75 commits and the codebase isn't that big, Git nevertheless must check out each version, one at a time, and commit it individually.
 For a project with hundreds or thousands of commits, this can literally take hours or even days to finish.
 
 The `-T trunk -b branches -t tags` part tells Git that this Subversion repository follows the basic branching and tagging conventions.
@@ -162,7 +162,7 @@ Git fetches the tags directly into `refs/tags`, rather than treating them remote
 
 ===== Committing Back to Subversion
 
-Now that you have a working repository, you can do some work on the project and push your commits back upstream, using Git effectively as a SVN client.
+Now that you have a working directory, you can do some work on the project and push your commits back upstream, using Git effectively as an SVN client.
 If you edit one of the files and commit it, you have a commit that exists in Git locally that doesn't exist on the Subversion server:
 
 [source,console]
@@ -375,7 +375,7 @@ But you need to provide a descriptive commit message (via `-m`), or the merge wi
 Remember that although you're using `git merge` to do this operation, and the merge likely will be much easier than it would be in Subversion (because Git will automatically detect the appropriate merge base for you), this isn't a normal Git merge commit.
 You have to push this data back to a Subversion server that can't handle a commit that tracks more than one parent; so, after you push it up, it will look like a single commit that squashed in all the work of another branch under a single commit.
 After you merge one branch into another, you can't easily go back and continue working on that branch, as you normally can in Git.
-The `dcommit` command that you run erases any information that says what branch was merged in, so subsequent merge-base calculations will be wrong – the dcommit makes your `git merge` result look like you ran `git merge --squash`.
+The `dcommit` command that you run erases any information that says what branch was merged in, so subsequent merge-base calculations will be wrong – the `dcommit` makes your `git merge` result look like you ran `git merge --squash`.
 Unfortunately, there's no good way to avoid this situation – Subversion can't store this information, so you'll always be crippled by its limitations while you're using it as your server.
 To avoid issues, you should delete the local branch (in this case, `opera`) after you merge it into trunk.