First ImpressionsFirst of all the cover photograph is gorgeous and in a nice high resolution. You can zoom in and see very fine detail, not relevant to the actual book but a nice touch nonetheless. Since I've read my share of poorly executed PDF eBooks the first thing I check is the table of contents and the index. I'm happy to report that both were done properly and are fully linked. The book even makes you feel special by customizing each footer of every page with "This material is copyright and is licensed for the sole use by <Your Name Here> on <Date you bought book here>". OK, the point is probably not to stoke my ego but to deter piracy. I feel they could have saved me some scrolling (and a few trees) by reducing the vertical footprint of the header and footer.
Target AudienceThis book is really going to be the most benefit to programmers who haven't used SVN or even any source code management (SCM) system before. I know lone programmers out there that still just make backup copies of their source folder every day or week and think that is sufficient. This is crazy thinking I tell you! Even if you are a team of one (like me) you should be using an SCM system. Of course, some programmers shy away from SCMs because the one they once tried was Microsoft's Visual Source Safe. They were right to run and hide from VSS. TortoiseSVN is not VSS, the only thing they share is the fact that you can get them both for free. If you aren't using an SCM because of the learning curve involved, then this book is definitely for you. The author does an excellent job of hand-holding and walking you through the most common operations for day to day use. A lot of examples assume you work on a team, but even if you don't a lot of the information is still relevant.
Teaching Old DogsIf like me, you already use TortoiseSVN, you'll find the book less valuable, but you'll still probably learn several things. The book is an easy read and well organized so I found it a pleasure to sit down and read cover-to-cover over the weekend. Even though I know where to find some of the information in the help files, reading it in the book forced me to get a better overall picture. One example is the section on the SubWCRev command. I was already using it but after reading the book I was able to fine tune the output to exactly replicate my preferred version naming scheme. It was also nice to learn about some of the features that are more relevant to team use of SVN. Since I work alone I haven't really explored those parts of the program or help files but now I have confidence in how to use them should the need arise. I also learned that you can format comments in your log file. Not sure I'm going to bother doing that, but I never even knew it was possible.
The Good the Bad and the UglyI hope I've already covered the good. The book is well written, well organized and decently indexed (although I think the index could have been more comprehensive). The material chosen for coverage is for the most part valuable and covers most of what you need to know to use the program on a day-to-day basis. The author has also included valuable links to other resources that can improve your programming life.
Just so you know I'm not a corporate shill, I think the book missed a few key concepts. The Import in Place" feature was not mentioned at all. If you're just coming to the joys of an SCM then you have existing code and you'll want to start off by getting that code into the system. The TortoiseSVN help file gives prominent mention of this technique so be sure to see it. I'm perplexed as to why this was missing from the book.
The other common thing you're likely to be used to doing is rearranging folders of your source code. This has to be done with care once you have code checked into an SCM. It can still be done and TortoiseSVN fully supports it, but it's easy to forget and just use Window's Explorer's copy and paste and forget to right-click and use Tortoise SVN's paste command. Again this is a surprising omission from the book but you can learn about it from the help files. There is also no section on common errors you might get when checking code in to TortoiseSVN and the steps for recovering from them. This might not be appropriate for a "beginner's" book, but I would like to have seen some information on it. I would also like to have seen PROMINENT mention of the fact that Window 7's indexing and TortoiseSVN do not get along and you need to not index your source code.
In terms of structure, the book uses a "quiz" section as a summary technique. I didn't particularly like this technique. I would have found a simple summary of key points section more succinct and valuable.
Finally, the one bit of ugliness I found was the implication (and it wasn't directly stated) that you should continue to keep commenting your code with reasons for making changes. I completely disagree with this. I think the author should have taken the opportunity to point out that reasons for code changes belong in your SCM and bug tracking system not in your code. The only thing worse than having to wade through old comments about why code that no longer exists was changed is a huge header comment that lists all the revisions for that file. That's what unenlightened programmers who don't use an SCM do. Keep your CODE CLEAN. Put all the comments, reasons, debates, and blame in the SCM not the code. If you have trouble remembering what you changed, check in more frequently. If you have a technique you don't want to forget so you've commented it out and left it in the code DON'T. Give it some kind of log comment you'll be able to find with a search, check it in, then delete the unused code. Just one more joy of an SCM. Old code never dies, it lives forever, but only in the SCM system.