Here are some more answers to questions asked during the “Subversion in the Enterprise Webinar”. I  picked a few that seem to come from people who are starting to familiarize themselves with Subversion.

What is meant by global revision numbers? Are individual files not controlled?

Users of most other version control systems are used to version numbers changing at the file level (the revision number changes when the file changes). As a result, if there are 5 files in a tree, each file can have a different version number.

The problem with this approach is that it does not give a unique version number to the set of files that makes the entire tree. This complicates communication because when you talk about version 4 of a file you have to look up what the version numbers are of related files before you can talk about the complete set.

When you commit changes to Subversion, the revision of the whole repository is increased by one, even if only one file was changed.  This has a key advantage: you can now talk about the revision number for the entire tree. It takes a mental change that you’ll soon love: when you switch to Subversion the question “What is revision 5 of the file?” is not really correct anymore. You should ask: “What did the file look like in revision 5 of the tree?”

You said a Branch is a copy of a Directory. How is it accomplished without taking disk space?

Subversion does not technically have branches or tags, it has copies of directories. Subversion handles copies in a smart way. When you “branch” a directory, Subversion does not make copies of the files (why make identical copies in a version control system?). Instead, a branch starts as a reference to the original directory, a very quick operation. After the branch is made, Subversion only tracks changes relative to the original files. Disk space to create a branch is therefore almost zero and the branch can be created in a very short time. This is a key advantage over most version control systems because they create redundant copies of files, which takes a long time and leads to performance problems as their repositories grow.

In Subversion, branches and tags are essentially the same. Any suggestions/recommendations on when to use one or the other?

As explained above, Subversion does not really know about branches, instead it makes “cheap” copies of directories. Branches and tags are names for these copies and we use two terms to describe different use cases.

Typically you make a branch so that you can control and isolate the changes from other change activity that is happening in the repository. Think about maintenance of a shipping product on a branch, while at the same time working on a new release on the trunk. Another use case is working on a large feature that can destabilize a build. Doing this on a separate branch means that other developers can create builds that won’t be affected by the work on that branch.

Tags have another use case. They are used to “set aside a revision” and keep it unchanged. One use case is to keep a version of the code of a shipping product; corporate governance might dictate that and you’ll need it to hunt down defects.

Technically you do not need tags because the exact state of each revision is already in Subversion of course. You could just remember that revision r8810 was used for Release 1.0. But will you remember this? Isn’t it easier to create a tag and call it “Release_1.0”?  Tags are also convenient if you have external consumers of your project code and you want to give them an easy way to grab a specific published version of the code.

Does Subversion define the technology of its repository? Is it file based? DBMS based?

You have a choice. Originally Subversion’s backend used the Berkeley Database system. This is still supported but since version 1.1 Subversion can also use the operating system’s file system. Subversion calls that FSFS (Filesystem Filesystem, as opposed to BDB Filesystem). The Subversion development community has put a lot of energy into FSFS and since 1.2 it is the default backend. CollabNet recommends FSFS over BDB because it is more stable (less chance of wedges) and is easier to maintain and support. Read more about FSFS pros in Subversion’ own repository.

Is there documentation on both best and bad practices with Subversion?

We have a very popular document right here on openCollabNet: Subversion Best Practices. As for bad practices, great idea for a future blog post.

Scalability

There were quite a few questions on scalability. Like: “Can I use it with 200 developers?” Or: “Can Subversion handle half a million files?”

We get these questions all the time because scalability is an issue with many other systems out there; specially some of the big commercial ones. Competitive systems often fall over when you scale your deployment. They require or need one administrator for every few dozen developers, a heavy server for every 50 developers or the load corrupts your repository again before you fixed the last problem.

A typical Subversion deployment uses one central server and that’s probably why people worry: can one server really handle a thousand developers?” Yes, it can! Subversion does not need the server much. Developers check out files and work locally. Only in a few cases do they need to establish contact with the server; for instance to commit a change or to update their local working copy.  Because of its architecture Subversion scales very well. CollabNet has customers with thousands of developers using Subversion on inexpensive server hardware and with only one or a few administrators.  The Apache, KDE and GCC projects are examples of very large repositories with a lot of developers (5000+ for Apache).

Also, Subversion keeps the size of the repository small. We discussed that in an earlier post. But to be fair, the question: “Can Subversion handle half a million files?” needs context because it depends what these files are. I’m sure Subversion will behave differently with half a million large videos than with half a million typical source files.  Assuming that we are talking about the latter, half a million files is not a problem;  CollabNet has customers with more files than that.

Where can I get the Subversion Book?

There are a number of books on Subversion. The only English language book updated for version 1.4 is “Practical Subversion” by Dan Berlin and Garrett Rooney. If you read German, there is a Subversion 1.4 book for you. Another publication: "Version Control with Subversion" is considered the standard book on Subversion but the printed edition is not current with release 1.4. However, the authors are updating this book and because it is an open source project, you can always see the latest and greatest. Visit http://svnbook.red-bean.com  to read or download the original book or refer to nightly builds of the 1.4 update.