Slashdot Mirror
Pragmatic Version Control Using Subversion
Chapters on repository layouts, integrating third party code (into your source tree and products) and conflict resolution all help raise this book from just being a single application tutorial into a best practices guide that you'll come back to long after you've gained confidence with Subversion itself.
Pragmatic Version Control Using Subversion is very similar to Pragmatic Version Control Using CVS, but this is in no way a criticism! The previous book was the best introduction to CVS that I've read, and this related volume manages to retain the winning formula while adding useful sections, such as CVS hints, to help people migrating across.
While the book has a broad appeal, the ideal audience are those developers who know they should be doing version control but have heard it's too complex, have been burnt by previous mistakes, or just don't know where to start. Seasoned developers will also find this book useful, but in different ways. For instance, using it as an easy to scan and follow reference, handing it down to less experienced colleagues, or even just for quickly bringing themselves up to speed when moving from CVS to Subversion.
Considering the book's slim size (or quick download, if you purchase the PDF version) it packs in surprisingly wide coverage of the important topics. The first two chapters provide an overview and sell the benefits of using a version control system. They cover what should and shouldn't be under version control, and clearly explain the terminology required to understand both the technology in general and the book's later chapters.
Chapters 3, 4, and 5 get you working from your own Subversion repository and introduce the essential commands. They show how to create, add and import your projects in a clear, easy-to-understand way. Once you have some files to work with, they take you through a well-paced tour of the simple operations; checking out, committing and accessing the files in different ways.
Following these, Chapter 6, "Common Subversion Commands," shows some of the more complex but essential tasks you'll want to perform in Subversion; setting properties, looking at changes and their associated history and how to handle merge conflicts. These are all presented in short sections that provide enough information to be useful on a day-to- day basis while not leaving beginners bogged down in the minutiae.
Jumping ahead slightly, we leave the part of the book that everybody using Subversion should read and move onto the more powerful, and complex, functionality such as "Using Tags and Branches" (Chapter 8) and the more abstract topics of "Organising Your Repository" (Chapter 7) and dealing with "Third Party Code" (Chapter 10).
Chapter 8 stands alone in the second half of the book due to its coverage of a very technical subject; chapters 7, 9 and 10 are more abstract. Tagging and branching are one of the more notorious areas of version control, but this book -- much like the CVS book before it -- manages to explain not only when and how to use both tags and branches, but also provides enough guidance to allow the reader to 'smell' when something's wrong and adding them would make it worse.
Chapters 7, 9 and 10 logically combine to cover the issues surrounding setting up your own project, including the project's structure, the integration of third party code, external projects, and binary libraries such as Nunit or Java mock libraries. Considering the amount of maintenance coding (as opposed to new projects) that happens in the world, these chapters might not be immediately useful to a fair chunk of the readership. I don't think they should be removed, though -- better to leave them in and show best practices and experience-driven common sense than remove them and let people make the same mistakes over and over again.
It's worth noting that the appendices are a lot more useful than the filler material typically found lurking at the back of a book -- they cover a couple of topics that don't fit elsewhere and help round out both the book's coverage and appeal.
Appendix A is more relevant to system administrators than developers. It shows how to install Subversion on the server. It then gives a brief introduction to configuring, serving (using either the native svnserve, svn over SSH or via Apache) and adding basic security to your repositories. It finishes off with a short, but useful, digression into backing up your hard work.
This appendix provides a valuable, quick guide to getting a Subversion install in place. It's a good starting point for anyone who needs to actually run and maintain a Subversion server.
The remaining appendices vary in usefulness. Appendix B is a concise introduction to migrating a CVS repository to Subversion; this is something you either need desperately or won't care about. Most of Appendix C shows how to perform common tasks using the TortoiseSVN extension for Windows Explorer; this won't appeal to the Unix/Linux crowd but might help sway Windows developers away from the hell that is Visual Source Safe.
In short, whether you're new to version control in general or just Subversion itself, this book is highly recommended. Clear, concise and crammed full of useful, important and dare I say, pragmatic, advice and information. An excellent book in its own right and a worthy addition to the Starter Kit Series.
Dean Wilson is a System Administrator at Outcome Technologies. His personal site is unixdaemon.net. You can purchase Pragmatic Version Control Using Subversion from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
So as a crusty old fart who hates changing tools just because they are new and cool, and am pretty much happy with CVS, what is it that subversion does better than CVS that should make me want to switch?
And this is a real question asked for the puposes of gaining information, just just a snide "here is a nickel go buy a real computer" kind of remark.
We are switching from PVCS to subversion. Besides being pretty crappy and expensive, PVCS uses the lock/modify/checkin paradigm. Every time when I convert a PVCS user to Subversion they are scared because of the edit/conflict/merge idea. "OHMYGOD I have to lock my files or anything can happen". (Because I am not articulate) I have a hard time conveying the benefit of the CVS/subversion way.
My rationale is that if two people need to modify a file the conflicts exist independent of the version control mechanism, its just that locking serializes modifications and and merging has you modifying in parallel and then fixing it all at once, which is more efficient than making someone wait. Not to mention the idiots who lock everything and then go on vacation.
I usually just say 'try it and you will see that subversion is way easier to use and the rare conflicts are easy to merge'.
Any recommendations?
I've played with cvs, subversion, arch, darcs and I honestly think darcs is easiest to use and best of all of them I've played with.
The only thing I would change in darcs is the way it handles binary files. It can't apply patches to binary files, it has to save full copies of them. Not very condusive to projects with lots of binaries.
Subversion, on the other hand handles this better.
But I still like darcs better... its features are sweet.
Just install Subversion, configuration and maintenance is a breeze. Which makes me happy because I have to use it and administer it (or not in the case of svn:)
I love it so much, I am actually considering installing svn on my families computer so they can keep track of their most beloved digital documents as well.
JsD
I wonder if SourceForge will ever move from CVS over to subversion. Maybe they could setup a temp program to allow people choose which way they use. The benefits subversion brings to OSS soruce control is really amazing.
But it is hard to say how well subversion would handle the load. I'm guessing sf.net has done a lot of tweaking to get CVS to handle the number of projects they currently have, and moving everyone over... or just supporting both, is greater than the effort they want to put in.
Maybe some day...
Its not what it is, its something else.
I've been using Perforce for awhile for a personal project (their "trial version" is a perpetual 2-user free-as-in-beer license) and I have to admit, I'm hooked on the speed. CVS on the LAN at work is an order of magnitude SLOWER for edit/commit operations than Perforce on a 512K upstream DSL connection.
I've thought about moving to Subversion just so it would be cheaper if I ever had to scale my "personal project" up past two people. But honestly, I think Perforce is well worth the US$750/seat for the sheer speed it offers.
Anybody have any idea how SVN compares?
It's my understanding that the file system repository is also binary. I really like CVS's text repositories for two reasons. One, a vague sense of security, that if a file gets corrupted, I can at least make an attempt at manual repair. Two, I can do a quick read-only edit of a repository file to see some code, I don't have to waste time with checking it out, just go look. Grep also works on it. If I want to find some code that was put into Attic a long time ago, grep works wonders. I don't know how you'd do it with Subversion.
I also had a minor scare with moving subversion (with a Berkeley DB repository) from a Pentium to an Opteron system. The repository size, using dump and restore as recommended by the subversion docs, grew by (IIRC) a factor of around ten. I do not understand this. Merely going to a longer word size would have made no difference to a CVS or darcs repository, being text, and I could think of no reason to more than double for a binary repository. That is what prompted me to look for alternatives, and how I found darcs, and I won't go back to either CVS or Subversion.
Infuriate left and right
PuTTY converts to svn:/ svn.ht ml
http://www.chiark.greenend.org.uk/~sgtatham
(much) smaller project than mono, obviously; interesting all the same.
A few months back I got a job at a place that had started using subversion. I liked it enough to switch my main project to subversion also.
:-)
As expected, there were some hassles at first, due mostly to me not knowing subversion as well as I knew CVS. But in the end, my view is, it's much much better.
Improvements are what you list. The only minus that I've found is that the "svn:externals" entry isn't as good in some ways as the CVS submodule system...that is, if I have a several projects in a repository that share some library code, the only real way to do this is to pull the shared code in via svn:externals. But when you do this, you have to do separate commits on the project and on each so-called "external" library, even though they are all from the same svn database. In CVS, this wasn't necessary, you can pull in submodules all you want and they commit with one command (of course internally CVS breaks them up into separate commands due to the CVS multi-directory problems, but at least it looks like a single checking). It's not a huge issue, but it's the only thing I can find where subversion is clearly worse than CVS.
End result: the switch was definitely worth it to me. Love being able to move and/or copy files and have the history carry over. Love being able to truly delete a directory, not just blow away all files. Love the system wide version numbering. Love getting rid of the crufty x.y.z.p.d.q.r.s.t numbering system of CVS. Overall, once you have the system down, you'll be glad you switched.
The one thing that has me mystified is how svn seems to be corrupting my binary files.
I do a
svn add *
and it recognizes that a particular file (a CAD file) is binary, but when I commit, I see that the file size has increased and now my CAD software can't read the file!
What is svn adding to binary files? Surely not those properties you set with svn propset etc?
If you read a bit in the gcc ML about the switch one of their main points is, that they want a central server, something which arch does not give them.
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
We use Subversion here at my company and have had a great time with it. When we moved from CVS we had a few headaches but the documentation is so good that we had an easy time figuring it out. Now we have all of our projects in Subversion repositories. Life is good....
Then we loaded a project onto SourceForge. Back to CVS. I screwed up the initial import and had to remove a bunch of files. Do you know how this is done? By sending a request into SourceForge.
Already I miss Subversion.....
--
Dan