Note: These notes provide information about the legacy version control service, Apache subversion, which was set for decommissioning on 30-Sep-2016.
After requesting a new repository you will be given a name for the repository. In the examples below we've used myproject as an example repository.
The first thing you're likely to want to do is import your existing work into the repository.
Change the current directory to the directory that your work's stored in and run svn import:
(This will import all files under ~/[...]/myproj to the myproject repository)
Check out, Modify, Commit
To work on your files, first you need to check a working copy out of the repository. To do so, use svn checkout:
A new directory named myproject will be created containing your project files. You can work and modify them. Once you're done and you want to store the new revision in your repository, run svn commit in the checked-out myproject directory:
Subversion will open your default editor asking for a log message. Again, enter an explanation, save, and exit.
When someone else is also working on your project you need to update your repository to include their changes. To do so, use svn update in the :
Adding and removing files and directories.
To add a new file to subversion you simply need to run svn add on the file.
To delete a file from subversion you simply need to run svn rm on the file, which will delete your local copy of the file as well.
Working with Revisions
Now let's make real use of Subversion. While working with revisions, you can:
Compare different Revisions
(Replace R1 and R2 with actual revision numbers you want to compare)
Revert Local Edits
Revert to Previous Revisions
(Replace R with an actual revision number)
[filename] is optional; you can run the previous commands on the current directory if you omit it.
Deleting previous versions
It's not possible to delete a previous version, though an admin can effectively create a new clean repository via a dump. Hard coding credentials into code is a general security risk, should you accidentally commit hard coded passwords or private keys it would be best to consider them as compromised and change them. Whilst the repository itself is secure, shared access with other developers and future export of the code means that this safeguard in itself is not sufficient in the long term and alternative methods to hard coding for password access should be used .
This is a very quick start for using Subversion to control projects. For extended help on commands, you can always use svn help [command] to get a help message on [command], for example:
This will give a lengthy explanation on svn import.
In addition, check out "Version Control with Subversion" for detailed information.