Subversion News

Re: *** NOTICE: This mailing list is now CLOSED ***

*** NOTICE: This mailing list is now CLOSED ***

Subversion 1.6.6 Win32 Installer Released

Subversion 1.6.6 Released

Subversion 1.6.5 Win32 Installer Released

Subversion 1.6.5 Released

Subversion 1.6.4 Win32 Installer Released

Re: Subversion 1.6.4 Released

Subversion 1.5.7 Released

Subversion 1.6.4 Released

For detailed usage information about Subversion, see the ebswift.com tutorials for screen recordings of actual use here.

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 appropriate.

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 modified.

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).