What is Subversion?

Subversion ("svn") is a version control system; it manages successive revisions of files, keeping track of the latest version of each file, which versions of other files are associated with particular versions of a file, etc. It can be used to:

  • Get a copy of the most recent version of a file
  • Get a copy of a set of files as of a given date, a given version of one particular file, etc.
  • Compare the "working" version of a file to the most recent version
  • Allow multiple people to work on files at the same time
  • Etc., etc.

More SVN info:

  • Comprehensive svn documentation: http://svnbook.red-bean.com
  • Subversion website: http://subversion.tigris.org
  • [w:Subversion_(software)|Wikipedia article on Subversion]

    • The main terms you need to understand are "repository," "revision," and "working copy". The repository is a central store of all the versions of all the files that are under Subversion's control. A revision of the repository is an integer that uniquely identifies the states of all of the files in the repository. A working copy (aka "sandbox") is a local copy of one particular version of one or more files, which you typically edit, test, debug, etc., and then "commit" to Subversion, thereby creating a new revision.

    Client/Server Architecture

    Subversion has a client/server architecture in which the repository (all the versions of all the files checked into svn) lives on a server, and people access the files via clients.

    Basic Work Cycle

    Here's some great documentation on the basic Subversion Work Cycle: http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.cycle

    To summarize this summary,

  1. You must have a working copy. (svn checkout)
  2. Your working copy may be out-of-date because somebody else has checked in improvements since you checked yours out. Fix this (svn update)
  3. Make changes to your files.
    • If you're changing the contents of files already managed by Subversion, just edit the files normally.
    • If you need to change file names or directory structure, do it through Subversion (svn add, svn delete, svn mkdir, svn rename, svn copy, etc.
  4. Examine your changes:
    • Which files have I changed (or have changed in my working copy for some other reason)? (svn status)
    • What changes have I made? (svn diff)
  5. Commit your changes (svn commit). Please write a descriptive log message when you commit any file(s) to svn.
    • If somebody else committed a new version of this file between when you checked it out and when you're now trying to commit it, then you have a "conflict". If Subversion let you check in the file in this situation, then it would be throwing away the work that the other person did, which would be bad, so instead it informs you about the conflict. You then get to [http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.cycle.resolve|resolve the conflict] by merging the other person's changes with your changes. Once you finish you tell Subversion that the conflict has been resolved (svn resolved) and then it will again let you commit the new version (unless somebody else committed yet another new version in the intervening time...).
    • The best way to avoid this problem is always to update your working copy before you start editing something, and always to check in your improvements after you make them, rather than having them sit around in your working copy.

You almost never need to refer to the server in a typed svn command, because working copies remember where they came from. So when you say svn update, svn status, svn diff, svn commit, etc., svn automatically interprets these to mean "with respect to the working copy in the current directory and the repository it came from" and so you don't have to mention the server. The only exception is checking out a working copy in the first place; obviously if the working copy doesn't exist yet then you need to tell your svn client which server to get the files from.