Installing the SVN client
To install the client program, you can build it yourself from a source code release or download a binary package. The list of sites where you can obtain a pre-built Subversion client is available at the official binary packages page. If you want to compile the software for yourself, grab the source at the Source Code page.
Right after you install the client you should be able to test it by issuing the svn command. You should see the following output:
Type ‘svn help’ for usage.
Now you can start using the command line client to interact with the remote repository.
Importing data into the repository
In case you want to import existing non-versioned data into an SVN repository, you should run the svn import command. Here is an example:
$ svn import https://svn.example.com/repos/MyRepo/MyProject/trunk -m “Initial project import”
Checking out a working copy
To begin making modifications to your project’s data, you have to create a local copy of the versioned project. You can use the command line svn client or any GUI-based client that you prefer. Your local copy of the project is called a working copy and you create it by issuing the svn checkout command. Here is an example:
$ svn checkout https://svn.example.com/repos/MyRepo/MyProject/trunk MyWorkingCopy
As a result, you will get a working copy of the trunk of a project called MyProject that resides in MyRepo repository. The working copy will be located in MyWorkingCopy directory on your computer. Note that instead of checking out the trunk, you can check out some branch or a tag (assuming they already exist in the repository).
You can get the working copy of the whole repository MyRepo, too. But you should refrain from doing so. Generally speaking, you do not need to have a working copy of the whole repository for your work because your working copy can be instantly switched to another development branch. Moreover, Subversion repository can contain a number of unrelated projects and it is better to have a dedicated working copy for each of them, not a single working copy for all of the projects.
Updating a working copy
You are not the only person working on the project, right? This means that your colleagues are also making modifications to the project’s data. To stay up to date and to fetch the modifications committed by others, you should run the svn update command in your working copy. As a result, your working copy will sync with the repository and download the changes made by your colleagues.
It is a good practice to update your working copy before committing local modifications to the repository.
Making changes in your local working copy
Most of the time, you are going to perform modifications to the project’s data by modifying the contents of the working copy. As soon as you are satisfied with the modifications and you’ve reviewed them thoroughly, you are ready to commit them to the central repository.
Modifying existing files
Modify the files as you usually do using your favorite text processor, graphics editor, audio editing software, IDE, etc. As soon as you save the changes to disk, Subversion will recognize them automatically.
In order to publish the changes you made in your working copy, you should run the svn commit command.
Committing your changes to the repository
Review your changes before committing them! Use the svn status and svn diff commands to review the changes.
Here is an example of the commit command:
$ svn commit -m “My Descriptive Log Message”
Note the -m (–message) option. You should always include a descriptive commit log message. It should help others including yourself understand the reason why you made this commit. It is a good idea to include a summary of your changes in the log message, too.
Performing file and directory operations
You can perform any actions with your project’s data within the working copy, but operations that involve copying, moving, renaming and deleting must be performed using the corresponding svn commands.
Subversion does not use heurisic-tracking for tree changes in a working copy. Subversion requires explicit tracking of tree changes. If you perform a tree changes such as move or copy with regular filesystem commands, Subversion will not know about this operation. To track tree changes Subversion should be made aware of them.
Adding new files and directories
Put new files or directories to the working copy and Subversion will see them as “unversioned”. It will not automatically start tracking the new files unless you run the svn add command:
$ svn add foo.cs
Moving and renaming files and directories
Move and rename files and directories using the svn move or svn rename command:
$ svn move foo.cs bar.cs
The command svn rename is an alias for the svn move.
Copying files and directories
Copy files and directories using the svn copy command:
$ svn copy foo.cs bar.cs
Deleting files and directories
Delete files and directories using the svn delete svn delete command:
$ svn delete foo.cs
Reverting or discarding local changes
Discard your local uncommitted changes using the svn revert command:
$ svn revert foo.cs
Discarded uncommitted changes will be lost forever. You will not be able to recover the reverted changes. Use svn revert with caution!
Branching and tagging
You should use the svn copy command to create branches and tags. This is the same command that is used to copy items in your working copy and in the repository when you want them to be historically related.
The command svn copy is used for branching because branch is technically a copy of the source you copy from. However, it is not an ordinary copy that you are familiar with when copying files on your local file system. Branches in Subversion repositories are so called “Cheap Copies” that are similar to symlinks. Therefore, creating a new branch takes minimal time to complete and takes practically no space in the Subversion repository. You can create branches and use them for any change you want regardless of the change’s size and scope.
Creating a branch using direct URL to URL copy
Branching in Subversion is simple. In the simplest form, creating a new branch requires you to run the command against the remote repository’s URLs. For example, let’s create a new branch out of the mainline trunk:
$ svn copy https://example.com/MyRepo/trunk https://example.com/MyRepo/branches/MyNewBranch -m “Creating a new branch”