This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Subversion 1.7 Q & A, part 3
This is the third of, I predict, four posts containing answers to questions asked of my colleague Bob Jenkins and I during our recent Subversion 1.7 webinar. (For the previous posts, see part 1 and part 2 of this series.) Today’s batch of questions begin to deviate a bit from the primary topic of Subversion 1.7, but that’s okay — maybe one or more of these questions were on your mind, too.
Q: How does Subversion 1.7 compare with Git and Mercurial?
I think a full comparison of Subversion with Git or Mercurial might be a bit more of an endeavor than I’m willing to engage in at the moment, so I’ll shoot for a mile-high approach.
Subversion offers centralized version control, meaning that the primary storehouse for the version history is a repository in some central location, accessed by clients whose direct interactions are solely with the repository, not with each other. The Subversion client maintains only enough information as required to complete those interactions with the repository for the purposes of version control. Information is only shared between clients after passing through the central repository — a classic hub-and-spoke model.
Git and Mercurial offer distributed version control. The primary storehouse for version history in a DVCS is still a repository, but there’s no single central repository. Instead, each client has its own private repository against which it primarily operates, and the business of sharing information between clients is actually done by sharing information from one client’s local repository with another client’s local repository. Centralization of information can occur by policy, but is not a required component of this point-to-point model.
There are pros and cons to each type of system, and the Web is full of write-ups about these. Sadly, most such write-ups that I’ve seen tend to be quite biased, so as you further research this topic, you’ll need to crank up your FUD filter. But in general, I believe it can be safely said that the DVCSes excel in everyday performance and in the maturity of their merge algorithms. Centralized version control systems, on the other hand, claim ease-of-use and enterprise-friendly aspects such as path-based access control and, indeed, centralization of information itself as their high points.
Q: Can you create local topic branches in Subversion without sharing to the central server?
You cannot. This is precisely the sort of thing that a DVCS tool allows, but for which Subversion has not been designed. That said, the Subversion developers are exploring some related features (shelving and checkpointing) for future releases which we believe will go a long way toward alleviating the need to use a full-blown DVCS tool just to get some more client-side support for locally checkpointed changes which will be committed to the central server at a later time.
Q: Will Subversion be a distributed VCS some day?
The Subversion developers have consistently agreed that the version control landscape is not really in need of yet another contender in the DVCS arena, while there remains a need for solid centralized version control. Our project’s goal is to be the very best centralized version control system — no more, no less. Efforts spent completely re-architecting Subversion as yet another DVCS would be ill-invested.
Q: Is there a limitation on the size of any given branch in Subversion?
Not really. There are certainly some things that you could do in Subversion that would make operations slower — placing a gazillion files into a single directory, for example — but there’s nothing about those scalability characteristics which is specific to branches. After all, branches in Subversion are just directories.
Q: How do we backup Subversion? How can we test restores of those backups?
There are many different ways to backup your Subversion repositories. You’ll want to determine your needs as far as backup goes: do you need full backups, will incremental ones suffice, or do you prefer a combination of both? Sometimes the answers to those questions are found in what tools and resources are available to you. Sometimes they are found by examining your restoration needs: do you need near-immediate restoration in a failover scenario, or is a longer downtime event an acceptable cost in your situation? Version Control with Subversion covers various different approaches to backup in its chapter on Repository Administration. See http://svnbook.red-bean.com/en/1.6/svn.reposadmin.maint.html#svn.reposadmin.maint.backup for details.
In terms of testing restoration, I would suggest using the ‘svnadmin verify’ command. Actually, I’d recommend occasionally using that command against any full backups that you have, too, so that if corruption of a backup occurs for some reason, you can catch that before needing to rely on that backup.
Users of CollabNet Subversion Edge will be pleased to learn that Subversion Edge 2.1 — which bundles Apache HTTP Server, Apache Subversion 1.7, and ViewVC with an easy-to-use Subversion administration console — offers automated backup capabilities. (Not on the Edge? Download it today at http://www.collab.net/getSVN/!)
Q: I need CollabNet certified binaries, but don’t really want Edge. What are my options?
CollabNet continues to produce certified Apache Subversion binaries which are distinct from our Subversion Edge product. Visit http://www.open.collab.net/downloads/subversion/ as a starting point for locating all of our available packages. There, you can see package offerings by operating system, as well as an admittedly somewhat non-obvious link to http://www.open.collab.net/downloads/subversion/svn-other.html, where our non-Edge server packages may be found.
Q: Is your support staff US-based?
(That’s an odd question for a technical webinar, but …) The short answer is, “Yes, partially.” CollabNet is an industry leader in globally distributed development for a reason: for over a decade, we’ve been successfully practicing globally distributed development using the very same platforms and tools that we offer to our customers! Headquartered in California, CollabNet currently has six additional offices located around the world, empowering us to boast of 24×7 product support delivered by staff in several time zones.
* Apache, Apache Subversion and the Subversion logo are trademarks of the Apache Software Foundation. Subversion® is a registered trademark of the Apache Software Foundation.