Subversion

Subversion (SVN) is a version control system, used to maintain current and historical versions of files such source code, data files and documentation.

Subversion is well-known in the open source community and is used on many open source projects, including Apache Software Foundation, GCC, Python, Ruby, SourceForge.net, Tigris.org, and PHP. Google Code also provides Subversion hosting for their open source projects. Subversion is also being adopted in the corporate world by companies all over the world. Subversion is released under the Apache License, making it open source.

• Commits are true atomic operations. Interrupted commit operations do not cause repository inconsistency or corruption.
• Renamed/copied/moved/removed files retain full revision history.
• Directories, renames, and file metadata (but not timestamps) are versioned. Entire directory trees can be moved around and/or copied very quickly, and retain full revision history.
• Native support for binary files, with space-efficient binary-diff storage.
• Natively client/server, layered library design.
• Client/server protocol sends diffs in both directions.
• Costs are proportional to change size, not data size.
• Parsable output, including XML log output.
• Path-based authorization.

A complete online book with all the technical details is available here (if you really want to know more)

Subversion manages files and directories over time. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.

A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

On one end is a Subversion repository that holds all of your versioned data. On the other end is your Subversion client program, which manages local reflections of portions of that versioned data (called “working copies”).

Subversion can access its repository across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change.

One important note

DO NOT USE SPACES OR SPECIAL CHARACTERS IN FILENAMES

Why? IvAc is supposed to run on multiple platforms (Windows, Linux, Mac, …) and spaces are only supported on the Windows platform. Please keep this in mind - it will make life easier!

Branching is the ability to isolate changes onto a separate line of development, tagging is creating a _snapshot_ of the repository's content which unlike a branch is not expected to change in the future. Generally speaking a Tag is created when a release version is build. At a later stage, one can checkout a specific tag version to go back to the files used for a specific release. To Subversion, the only difference between tags and branches is that changes should not be checked into the tagged versions. Due to the differencing algorithm, creating a tag or a branch takes very little additional space in the repository.

This datastore is the “lock box” where Subversion stores the current and all previous versions of your code

Subversion increments the revision number every time code is checked in. It is essentially a unique ID for each transaction.

Version numbers are not part of Subversion. They are assigned by programmers according to their understanding of software versioning.

The working copy is whatever revision of the code a user has in their directory. This may or may not be in sync with the code in the Subversion repository.

The trunk/ directory in a Subversion repository should contain the latest, greatest, working version of the code and nothing else.

The tags/ directory is for tagging versions of code before embarking on significant code changes.

The branches/ directory is for those times when you will be making large, potentially damaging changes to the code base. It’s best to keep these separate until completed when they can be merged with the trunk/.

To have write access to the repository you need a SVN client.

There are different clients to choose from - the two major ones are:

• TortoiseSVN (windows only - explorer integration)
• SmartSVN (multi-platform - windows explorer & Mac Finder integration)
• svnX (Mac OS X)

A comprehensive list of SVN clients can be found here

Well that depends on your personal preferences. Kenny uses the command line version on his main development platform Linux and TortoiseSVN on Windows, Filip uses TortoiseSVN on Windows, command line on Linux and svnX on Mac OS X. You guessed it - the main development platforms for IvAc v2 are Linux and Mac OS X

I've tried to write a small svn-tutorial but you can also find a lot of great tutorials on the internet:

• TortoiseSVN Daily Usage Guide
• SmartSVN documentation

Why did we use SVN and not for example a simple FTP server?

Well, the answer is simple: not only allows SVN simultaneous working on the same files or group of files but it also manages multiple versions and revision history. It will also allow us to see which team members are just “riding the wagon”. For you as contributor, it allows you to keep track of your revisions, return to a previous version or to check the work from your colleagues.

Continue here to the Subversion tutorial.

Back to Index