I was first introduced to version control (and CVS) in college, about the same time I was introduced to Linux. At that time though, most of the projects I worked on were small and
After school came the real world, and the love affair with CVS didn't last long. As I learned (mostly through trial and error) how version control systems should be used, CVS steadily became more and more inadequate. I could see its potential, but it didn't measure up. Code was lost, fits were thrown, and hair was pulled. Still, CVS was the best free,
Several months down the road, I saw that Subversion had become self-hosting. "Well," I thought, "If they trust it with their own code, maybe it's time to take another look." Rolling up my sleeves, I sat down to play around with it. Once again, I had
Writing the Book
When I was first approached about writing a book on Subversion, my first thought was, "Why?" There's already an
Of course, this book aims to cover the nuts and bolts of Subversion as completely as possibleyou can't very well use Subversion to develop software if you can't use Subversionbut it does so in the context of how to do the things you want to do in day-to-day software development. The book also goes a step further: It explains how to expand on the built-in capabilities of Subversion to make the system work for you. In some places, that takes the form of example scripts or configurations. In others, it is merely ideas that you can expand to fit your software development process. This is not a book to sell a process. I do make suggestions here and there of what I think will work in certain situations, but you don't need to buy into my "exhalted process" to get the most from this book. Instead of showing you how you should develop your software, I show you how Subversion can make your process easier.