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
For those looking for Subversion documentation, there's also an excellent Subversion book, with electronic copy available for free, at http://svnbook.red-bean.com/
My only problem with Microsoft is the severity of bugs in their software.
...Subversion support is one of the most requested features on RubyForge.
Is there a StatCVS-type reporting tool for Subversion? I suppose StatCVS could be modified to support Subversion... there's been some discussion of it on their mailing list...
The Army reading list
The Subversion Book seems to have most of what you need to know and its free as in speech and beer.
from the review it does seem to have a couple of chapters about general project organization that aren't in TSB. Otherwise it the list of topics seems to be right out of the oreilly book.
Executive summary:
By the way, the GCC team is starting to make experiments with svn, and it looks like they might switch in 2 or 3 months.
The book isn't even available yet (see the link from bn.com). One must presume the reviewer got an advance copy from the publisher, who may have given it away expecting a favorable review.
What reason do we have to to believe that this review isn't complete astroturf? What is his relation that caused him to get an advance copy?
It may well be an honest review, but I'm inclined to be a lot more skeptical. Especially since there is no mention in the review of the fact that he got an advance copy.
Sample excerpts from the book are available in PDF format from the book website. You can also download the full Using Tags and Branches chapter artima.com (free login required).
<gripe>Most tech books these days have a page on the publishers website, and some offer a sample chapter for download. Book reviewers should include a direct link to this book page, and note what excerpts/chapters are available for preview, if any (and prevent people like me karma whoring).</gripe>
- Atomic Commits
- Faster tagging / branching
- Natively client/server
- Directory structure versioning
- File rename versioning
- etc.
Anyone have success stories in moving from CVS to Subversion? Any caveats?FWIW, the lock/unlock model (a.k.a., "reserved checkouts") is on tap for Subversion 1.2, according to the roadmap.
The Busy Coder's Guide to Android Development
There are also a few rants by Greg Hudson and Tom Lord about changeset vs tree-history. Search google
From the document:
Subversion's Features
When discussing the features that Subversion brings to the version
control table, it is often helpful to speak of them in terms of how they
improve upon CVS's design. If you're not familiar with CVS, you may not
understand all of these features. And if you're not familiar with
version control at all, your eyes may glaze over unless you first read
Chapter 2, Basic Concepts, in which we provide a gentle introduction to
version control in general.
Subversion provides:
Directory versioning
~ CVS only tracks the history of individual files, but Subversion
implements a virtual versioned filesystem that tracks changes to whole
directory trees over time. Files and directories are versioned.
True version history
~ Since CVS is limited to file versioning, operations such as copies
and renameswhich might happen to files, but which are really changes to
the contents of some containing directoryaren't supported in CVS.
Additionally, in CVS you cannot replace a versioned file with some new
thing of the same name without the new item inheriting the history of
the oldperhaps completely unrelated file. With Subversion, you can
add, delete, copy, and rename both files and directories. And every
newly added file begins with a fresh, clean history all its own.
Atomic commits
~ A collection of modifications either goes into the repository
completely, or not at all. This allows developers to construct and
commit changes as logical chunks, and prevents problems that can occur
when only a portion of a set of changes is successfully sent to the
repository.
Versioned metadata
~ Each file and directory has a set of propertieskeys and their
values associated with it. You can create and store any arbitrary
key/value pairs you wish. Properties are versioned over time, just like
file contents.
Choice of network layers
~ Subversion has an abstracted notion of repository access, making it
easy for people to implement new network mechanisms. Subversion can plug
into the Apache HTTP Server as an extension module. This gives
Subversion a big advantage in stability and interoperability, and
instant access to existing features provided by that
serverauthentication, authorization, wire compression, and so on. A
more lightweight, standalone Subversion server process is also
available. This server speaks a custom protocol which can be easily
tunneled over SSH.
Consistent data handling
~ Subversion expresses file differences using a binary differencing
algorithm, which works identically on both text (human-readable) and
binary (human-unreadable) files. Both types of files are stored equally
compressed in the repository, and differences are transmitted in both
directions across the network.
Efficient branching and tagging
~ The cost of branching and tagging need not be proportional to the
project size. Subversion creates branches and tags by simply copying the
project, using a mechanism similar to a hard-link. Thus these operations
take only a very small, constant amount of time.
Hackability
~ Subversion has no historical baggage; it is implemented as a
collection of shared C libraries with well-defined APIs. This makes
Subversion extremely maintainable and usable by other applications and
languages.
The truth is an offense, but not a sin.------R. N. Marley
The general idea is that in a given set of interrelated files, it does not make sense to think about revisions on the file level, as a change to one file is really a change to an entire project. Simply assigning revision numbers on a repository-wide basis simplifies the revision number system and does away with one bit of weirdness in CVS. It's a bit strange if you're coming from a system that works with per-file rather than per-repository versions, but it makes a lot of sense when you get used to it.
As to difficulty tracking the files -- no, it's not difficult. Finding the revisions associated with changing a file is easy, so tracking the changes is no more difficult than in CVS.
How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
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.
If you're using Windows, look into TortoiseSVN, a Subversion shell extension for Windows. The neat thing is that you it doesn't even need a server if you file access to the repository is available (and possibly in other cases as well). This means it's the only program needed.
As for myself, I actually use it for school homework in addition to my programming projects. I setup a dedicated server for my repository in this case so that I could access and synchronize my work at school. It works wonderfully, especially when used with plain text documents or source.
Subversion isn't the only choice for people looking for relief from SourceUnsafe. CVSNT is an evolved and mature CVS that you should look at too.
http://www.cvsnt.com/cvspro/ for the server
and http://www.wincvs.org/ for a gui client
Mergepoints in cvsnt are very cool and wincvs is a powerful client. Since cvsnt runs on Windows and many unixes, you also have your choice of platform as well.
cvsnt is a project that has been around over five years (at my reckoning) and has a good following. Plus you can get commercial support for it from March... what more can you ask for from Free software?
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
Perforce is undeniably better than SVN.
:-)
It has the ability to collect changes for grouped check-in against an issue. And it has the excellent, albeit somewhat clunky GUI. I loved using Perforce and I recommended it.
However, after trying SVN, I would have to say that Perforce is not $750 per seat better than SVN. SVN has most of the functionality I looked originally to Perforce to get (mostly the atomic commits) and it is slowly but surely maturing.
The GUIs are coming along and even the ANT and Eclipse plugins. And eventually SVN will have a more fully implemented WebDAV interface (Perforce does not).
I feel bad that now that SVN is getting up to speed that Perforce is going to lose out. However, this is something that is happenning across the entire Developer tools market. Everything in the developer tools market space will eventually go Open Source. (most already are)
Perforce had their run and now they will need to branch out or make a new version of themselves by adding on significant new features.
Or otherwise they will disappear from the market. If so, they will be missed.
Subversion now has a file system version as well, so you aren't stuck with Bezerkly db if you don't like it.
Try Tortoise SVN. It's a pretty, integrated windows subversion client.
TortoiseSVN is an excellent front-end, and there are a bunch of IDE plugins for integration with things like Eclipse, IntelliJ, Visual Studio...
http://tortoisesvn.tigris.org/
Besides Tortoise, you should also check out RapidSVN. I tried them both and I like the RapidSVN Gui better. Both of them are open source.
Since SVN people are about, could some answer these two questions. How's the branch switching code looking nowadays and what's the status of read-only files in the repository?
We tested Subversion in November against our working CVS system. It was fun, and we were all really happy with it until...
When switching between two branches, a file that was moved caused the switch to fail. The local sandbox was broken to the extent that nothing short of re-rechecking out the repository would fix it. All subsequent commits, updates, or attempts to switch back would not work.
The second thing that bit us really bad was that we have applications that set source code controlled files read-only. This is intentional and necessary; if they are not read-only, the files will be changed automatically when certain tests are run which is something we do not want. Despite this, there are times when those files need to be updated. SVN crashed and burned trying to checkout changes over read-only files. All the research reading mailing list indicated that the prevailing thought at the time was that read-only meant read-only from SVN.
That's not how it works in CVS at all where we currently use watches and locks to get this functionality. Read-only is an attribute of the file. When some checks out the file, it must be read-only when it arrives in their sandbox. The file and the sandbox is managed by source control so aside from user permissions, the last word on whether a file can be modified is that of the sandbox manager, not the filesystem. In short, if CVS or SVN need to write over a read-only file they should be able to do it so long as the file is read-only when the job is done.
With the read-only detail and the sandbox corruption issues open, we had no choice but to return to CVS. I am seriously looking forward to what Subversion has to offer in the future though.
Hope
Except, most importantly, imoprting a large CVS repository is most certainly NOT a breeze. And by large, I mean decades old, having gone originally from RCS into CVS.
I have a zero chance in convincing my coworkers to switch to svn if we cannot preserve CVS history. Period.
I've been trying for months to get a test import into svn, and still doesn't work yet. That that it takes a few days to import doesn't make it any easier - by the time, if it doesn't bomb out, it's done I've totally forgotten about it.
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
I introduced the company I work for to Subversion. They now use it will all new projects. All prior existing projects still use CVS. I also created a full featured (including per project, directory level permissions with inheritence capabilities) web-based client in PHP that is tied into dotProject. Most web based interfaces to SVN that I found back when I started the project failed to consider that some people need restricted access.
Most people just use Tortoise though. The web-interface is nice for browsing repositories and downloading single files but when you need more stuff done, then Tortoise is ideal.
Work Safe Porn
About two years ago, I switched a large project from CVS (three years of revision history) to Subversion.
We were able to migrate it all easily. We have developers using both WinXP and Linux. The Eclipse client was kind of broken at first, but recent versions have been acceptable. I've been able to forget all the workarounds and weird issues that caused us headaches with CVS.
Overall a very good experience - I would say Subversion doesn't add anything groundbreaking to revision control, but rather is CVS done really really well.
The real concern we had in a similar conversion was trusting what actualy ended up as the last checked in code, and how to track contention on common code being worked on. In reality, even with decent sized teams, its easy to know in general who is working where in the code base - the managers and team leads should know, people paying attention to a check-in log should see the traffic too (assuming the change notices go to a distribution email list).
For knowing what is last in still works as intended, update to latest checked-in code prior to doing your own check-in, establish a process to run a unit test case suite for the project; these must pass 100% before checking in the new code. This is good practice anyways regardless of this situation.
Also, encourage check in early and often to minimize changes between source tree updates.
Have an automated build and/or a unit test runner, email a VIP list and the culprit that broke the build. This finds the issues early if people aren't actually using the process described above, which will help to enforce it.
I've used a process like this on teams with 20 people running for a year or more with 3-5 branches on the go at once. The problems are minimal. The hardest part is running 2 very active branches together for an extended duration; the merge is hell but all source systems will have this as an issue.
From the Nov 2004 sitewide update email: "For year six [2005], we have a lot of exciting things planned, including UI updates, enhanced tools, new tools, and Subversion support (version control). It will be an exciting year. We can't wait to show you."
It is coming along quite nicely... recently basic synchronize features were introduced, and the JavaSVN layer improves on a rapid pace (using it to avoid JavaHL). The installation thanks to a new update site by Alex Kiatev of the JavaSVN Layer is a breeze now, just point eclipse to it and watch getting it installed. But yes... the plugin has bugs, but there is only a handful of maintainers and getting everything to work correctly is a huge task (the devs definitely need a helping hand to get the rest of the functions in and improve performance, which is a drag once the project gets bigger... *IBM anyone?*