An Introduction to Subversion
Here at SolutionsIQ, more often than not, we use Subversion as our source control system. I’d like to provide a short introduction to the terminology of Subversion as a launch point for future posts. This post will probably be rather light for developers already using Subversion, but might be of assistance to those who have heard about Subversion and would like to know a little more.
Subversion provides a server that responds to requests from clients to commit or checkout code. These are the actions that put or get, respectively, code from a server that is typically shared by a development team (or teams). One Subversion server may host one or more repositories. In order to avoid delving too deeply into the topic in this post, I’ll simply suggest that a repository be devoted to a single project team, though there may be reason for team members to have access to repositories for other teams.
Within a given repository there are a number of possible ways to organize files; I’ll save the descriptions of these top-level structures for a later post. Subversion convention, though, suggests a given stream of work (I’m explicitly avoiding the term project here) be provided the following structures (just think of them as directories): trunk, branches, and tags. Development of the next version of a given application should occur on trunk: the files under the trunk directory should correspond to the files on a given developer’s workstation when checked out.
Branches are used when two streams of work must emerge from one set of files. For instance, if a product is released but development of new features continues on trunk,the dev team can create a snapshot of the code at the point of release and label it as a branch. In this fashion, any bugs that are reported should be fixed on the branch (which, recall, is identical to the released code) and a new release cut from that branch, fixing the bug but without risking the introduction of new bugs by bringing in new code from trunk. Tags are really no more than branches that have no changes applied — a tag functions as a label for a snapshot of code and the tags directory simply provides a convenient organization mechanism for these labels.
Developers typically only need to know a few commands in order to use Subversion (though most will use TortoiseSVN or an IDE like Eclipse to manage their files rather than a commandline client). These commands include: checkout which obtains a copy of the code, commit which saves a copy of the code to the repository, and update which brings the already checked out code current with the repository, thus downloading changes made by other developers since the the last update or checkout command.
This post has introduced only the basics of Subversion. In later posts, I hope to speak more to the structure of Subversion repositories, as well as to the tools used to access and manage Subversion repository contents.
Tags: tools