to keep the repository content consistent all the time. Second, all changes forming one logical set can be grouped into one commit, making it easier to audit WHY – (why was particular change done?) or vice versa, to audit WHAT (what changes were done to implement some feature or to fix some bug?) In Subversion terminology the change done by one commit is called a ”revision”. We speak about “committing revision 123” or about “revision 123 of the repository”. Subversion revisions are assigned ordinary numbers starting with 0 and incrementing by 1.
What About Branching and Tagging?
So far, you should be able to understand that Subversion is basically a versioned file system which keeps track of all changes and enables you to see the whole history at any time. Subversion keeps things simple. But now you might ask: if this is all, then what about branching and tagging? This is the must-have feature for any CM system!
The answer, shocking though it may seem at first, is: there is no special support for branching and tagging in SVN. Once you get past the initial astonishment, you soon discover that the reality is that SVN’s directory copy operation, with it's constant time and disk usage complexity, is an ideal candidate to replace the explicit branching/tagging of CVS.
This is where the magic trio “trunk”, “branches”, and “tags”, which you see in most SVN repository structures, comes into play. “Trunk” is the directory where all the main development takes place. “Branches” contain copies of the “trunk”; it’s where branched development takes place. Finally, the “tags” folder holds copies of the “trunk” folder acting in the tag role. Since the SVN tracks the copy operation, it is easy to find out when a particular tag was created, or to merge changes between trunk and branches. It's also useful to note, that since a revision number fully defines the repository state, the revision number alone can be used as kind of tag. For example, ”the build was created from revision 234”.
A Few Practical Basics
And now from the abstract concepts to some practical information. SVN supports three repository connection protocols: file, a proprietary protocol, and WebDAV/DeltaV.
The file protocol is useful for local repository handling, without any network overhead (versioning your files locally). The proprietary “SVN” protocol is easy to set up by just launching the command line server tool. The most widely used HTTP-based WebDAV/DeltaV protocol uses Apache HTTP server as the host platform. This is preferred, because of non problematic network setup (HTTP gets through most firewalls), security (when configured as HTTPS) and robustness provided by Apache HTTP Server. The SVN and HTTP protocols allow user authentication with path-specific read/write access control.
The SVN distribution (both client and server) is available for various systems, including Windows, Linux, BSD, Solaris, and MacOS. There is a choice of file system or Berkeley DB based storage implementation, with the file system being the more reliable (and therefore recommended). Repository storage is binary compatible among different systems.
Finally the good news for non English speakers: Subversion is localized to many languages and open to contribution of new localizations.
Stay Tuned For More
This concluded Part 1 of the series. In the following parts the series will cover Subversion installation and describe the most popular clients (part two), will give you a guided tour of the most frequent Subversion use cases (part three), and finally will give you some hints for the process of migrating from another RCS to Subversion (part four).
Subversion Home - http://subversion.tigris.org/
SVN Book (complete Subversion description and reference from