Using Subversion for your Source Version Control

Three Additional Commands

Before committing your changes to Subversion, you should examine them to make sure everything is as expected.

STEP 2'. Reviewing your changes.

You can review your changes by using the status command:
> svn status
You will then obtain a list of all the files that have changed. In front of each file in that list, there will be a letter describing the nature of the change, the most common ones being: 'M' for a file that has been modified; 'A' for a file that has been added and; 'D' for a file that has been deleted. These are all normal status for files and directories as long as they correspond to changes you made.

You must however pay attention to some special characters. You can obtain a '!' if a file that has disappeared; this means that you probably deleted a file on your local disk without telling Subversion: you should or declare it as deleted using svn delete or restore it using svn revert. You can also obtain a '?' Which means that a file is not under version control, i.e. you have added it without telling Subversion using svn add; it is still time to do it.

Another useful command is:

> svn diff filename
This command will describe the difference between a file on your local disk and the corresponding file on the repository. So, in doubt, you can always double-check what changes have been made before committing them. Note that you can also use svn diff to show the difference between two revisions of the project (here between revision 312 and revision 325):
> svn diff -r 312:325 svn://

ALTERNATIVE STEP 1. or STEP 2''. Updating your project files.

When you start working on your project, you generally start by checking out a fresh copy of the project on your local machine. However, if you already have a copy of the project on your machine it is possible to simply update it with the latest revision. This way you will avoid downloading the full set of project files if only few of them need to be updated.
> svn update
Another situation where you need to update your project files is just before committing your changes. When you work in team, it is important to always update your local project files in order to verify if your changes are still compatible with the changes made and committed by the other developers since your last check out. A svn update always give you a list of all files that have been updated. Like in the case of svn status, a letter in front of the filename will indicate how the file has been updated: the letter 'U' means that the local file has been updated with a new version (i.e., you have not touch this file, but a new version was available in the repository); the letter 'G' indicates that your changes has been merged with the changes made by your colleagues to produce a new version of the file. These two situations are normal and of no concern. The letter 'C' is however more problematic; it indicates the occurrence of a conflict. In this case, you will have to meet with your team and find a way to resolve the conflicting changes.

Top of the page


(c) Robert Laganiere 2011