For detailed usage information about Subversion, see the ebswift.com
tutorials for screen recordings of actual use
Subversion is the ultimate version control tool. I won't go into the
history of it, but it is CVS grown up, transformed and on steroids. You
can run a standalone local repository, a networked repository on a UNC path, or
a global repository placed on a web server.
An open source project, Subversion is among the elite in the open source field.
Many small and large companies are dumping their commercial version control to
use Subversion because of its shear power, reliability and economic sense.
That is not a spin, it is the reality of Subversion in its recent maturity.
Various plugins, both commercial and non-commercial provide an interface to
software that companies connect to source control software.
It's funny how many people consider version control to be overkill even for
their simple meagre needs, but I have quickly learned to put almost EVERYTHING I
have under version control where I will be making revisions.
The penultimate tool for programming sourcecode, graphics design, modelling,
multimedia projects, documents of any description, captured data, config files,
ANYTHING that is going to change over time, Subversion is the tool for the job.
Changes are recorded atomically for both text and binary files. Depending
on the type of binary file, the recorded changes can be large at each revision.
Although subversion is built on a principle of merging changes it has recently
implemented locking as a result of pressure from industry which is reluctant to
move to a merging model and more strictly enforces control over individual files
by way of locking. There is also the issue of merging binary files - it is
not possible to automatically merge binary formats, so locking may be more
Basic Subversion Principles
Simplistically speaking, the use of subversion involves creating a repository,
creating a structure inside that repository, importing the files to be version
controlled into the structure (usually the trunk of the structure),
then checking out a working copy of the trunk which can then be
At any logical point, the working copy can be checked in to the
repository which records any new changes made to any of the files in the working
copy. A check in also records a log message supplied by the person
checking in describing the changes made at that point.
The trunk should be maintained in a working state, especially if others are
working on the same project. If the project is a programming project, then
if your changes cause the project to fail at compiling then no other developer
can compile the code to check their own work until your bring the code back to a
compilable state. Likewise if you are working with a policy document and
you decide to restructure it, but leave out the headings, it can leave it in an
ambiguous state when others attempt to maintain their part of the document.
Occasionally when working with files we wish to look at our work before
major changes were made. Without source control w are forced to refer to
backups that hopefully were kept regularly. Subversion allows you to
easily checkout any revision that was checked in.
Along with standard working revisions you can also tag versions in the
repository. Such as when you release a version of software, or an approved
version of a policy document. Tagging is simply the act of
recording a revision (or the current working copy) into its
own folder in the repository (usually inside a folder called tags), and
the folder is generally named to reflect the tagged version, and the log file is
recorded with a description of the tag. A tag should be treated as a final
version, therefore it is no longer revised and kept in a static state.
So, with tagging, if someone were to retrospectively ask you what the company
policy wording was in August last year, you would quickly review the tag log to
find that period of time, and checkout the associated tagged policy.
Quick, effective, and simple.
The final common part of the Subversion structure is branches.
The act of branching a project is exactly the same as tagging
it, except you place the files into a separate part of the version control
structure (generally labelled branches) with its log recording the
purpose of the branch.
The main difference between branching and tagging is that a
branch is dynamic. You can continue making changes and checking
them in after branching. The idea of branching is
generally for experimental work, or separating a major part of the design from
the more defined trunk of the project. As mentioned previously,
the trunk in general should remain in a working state, whereas a
branch may be maintained in a non-working state. In some projects
where a number of developers may be working on one branch, the policy
may be to maintain the branch in a working state.
It should be stated that branching and tagging does NOT make a copy of all your
files; remember that Subversion records changes atomically, so copying a
revision to a tag or a branch simply creates a pointer to that revision, meaning
that the entirety of the tag or branch may only be a few bytes. Subsequent
commits to a branch will record only the atomic changes inside that branch, so
if you add, say, a few functions to a sourcecode file, the entire contents of a
branch in the repository will add up to the size of the functions added, along
with the overhead of the revision pointers (which are very small).