Difference between revisions of "Subversion"

From Spherical
Jump to: navigation, search
(created from http://web.archive.org/web/20120910131922/http://www.spheredev.org/wiki/Subversion)
 
(No difference)

Latest revision as of 22:35, 31 May 2013

Totally confused as to what the heck Subversion is? You came to the right place.

Subversion is a simple system designed to handle different versions of a group project (hence the name.) Using it, you can easily grab the latest copy of a project. Or you could jump to any point in the past, and grab a version of the project at that point in time effortlessly.


How does it work?

Subversion works on a client-server model. Take a website, for example. You use a client (usually a web browser like Firefox or Internet Explorer) to access stuff on a web server. The web server sends back the page you asked for to the web browser, and the web browser displays it.

Subversion works in a similar way. Instead of serving web pages, it serves a bunch of files, usually glomped together in the form of a project. The client programs are just called Subversion or SVN clients.

Subversion can track and store changes efficiently. When a text-based file on a Subversion server is modified, only the changes are stored. Logs are kept of what changes are made, and when, so you can jump to any point in time, and look at what the project looked like at that point.

I need a Subversion client

On Windows, the easiest client to use is TortoiseSVN. Just download and install it. After it's installed, options for use will appear in the right-click context menu inside Windows's file browser (Explorer).

For most any other system, there's the official SVN client, ironically named 'svn'. Under Linux, find it and install it using your distro's package manager. When installed, you can type in easy-to-use commands in a terminal to work with Subversion.

Why bother?

If you are convinced that using Subversion is acceptable, you needn't read this section.

Scenario: Imagine two people are working on the same file of a project at the same time. Alice saves her work, and then Bob unwittingly saves his work right over Alice's. Alice's work is now lost forever. Oops.

If Alice and Bob were using Subversion, the system would have done one of two things:

  • If the work doesn't intersect in the file, automatically merge Alice's and Bob's changes.
  • If it does, tell Bob that his version conflicts with Alice's. Bob can now contact Alice, come up with a common solution, make the new changes and save that.

Another scenario: imagine that Alice, Bob, Steve and Jess are working on a project. They write their source modules, and things are working out. But Jess finds a bug in Steve's module. She repairs the change on her own computer, makes a patch, and sends the patch to Steve. Alice, Bob and Steve also find bugs, and find and send patches to each other, via email or IM.

Soon, dozens of patches are flying around, and nobody is sure which to apply or in what order. The Unix patch program can't work it out. Eventually, they give up and simply neglect the bugs. Oops.

If Alice, Bob, Steve and Jess had turned to Subversion, they would always be able to see the latest changes in one place. It would be easy for Jess to find out what changes she made to fix Steve's bugs, compared to the latest version. The latest version of the project is always in one place.

Further reading