Work is done in a working copy of all or part of a repository tree. You normally make changes only in working copies, propagating them to the repository with Subversion commands. Repository working copies are normal filesystem trees with additional .svn subdirectories in each directory. These contain system information including repository URLs for each file and directory, and pristine copies of repository files in the most recently updated state.
You will be the owner of working copy files and directories which you check out or update. Repository files are usually owned by a system user, and repository access is independent of working copy file ownership.
Subversion is a cross-platform tool, and the file and directory access permission systems of Unix and MS Windows are completely different. For this reason, permissions are not managed by Subversion, except crudely for execute permissions as described below. With this exception, the user's umask is applied to all checkouts and updates. Generally this isn't the issue it sounds. Where it is, there are several automatic solutions: set the required permissions in hook scripts, or use a third party property-based tool.
Execute permissions are handled crudely in a Linux context. If the user execute bit is set for a file when you first check it in, Subversion will set the svn:executable property for the file. The next time you checkout or update you will find that all the execute bits will be set. If you change execute bits after a file has been first checked in, the changes will only last until the next checkout or update. Within this all-or-nothing scheme, to turn off execute permissions do
$ svn propdel svn:executable filenameand to turn execute permissions on do
$ svn propset svn:executable '*' filenameMore about Subversion properties in a future revision of this tutorial.
If you have access rights you can create as many full or partial working copies of a repository as you need. If the repository is accessible in the local file system, you can do this with
$ svn co file:///path/to/repos/[path/inside/repos]or if it is accessible over the network by http, with
$ svn co http://hostname[:port]/path/to/repos/[path/inside/repos]
To bring your working copy into sync with the repository, following changes other team members may have made, do
$ svn updateAt this point you will be told about any conflicts between changes you and others have made, as determined by Subversion. You'll have to resolve these by further editing.
To bring the repository into sync with your working copy, several commands may be required. If more than one person is working on the project directory tree, the first step should be to update your working copy as just described. Then do
$ svn ci
To export a Subversion-clean copy of a working copy tree, with .svn files removed, do
$ svn export pathnameThis would be the first step in creating a tarfile release of a project.
To add files or directory subtrees to the repository, first create them in your working copy, then
$ svn add $ svn ciLike many Subversion commands, these work recursively in the subtree from the current directory. Append filename arguments to restrict.
You can edit files freely in your working copy, using any editor or other tool. In the mode of use described here there is no file locking, and several team members could change a file at the same time. Subversion will detect what it regards as conflicts when you try to check in to the repository. You will then have to resolve any conflicts by further editing. In a small team with good planning it should be easy to avoid much need for this.
You must use Subversion commands to change working copy structure. To remove content, do
$ svn rm <path names> $ svn ciand to move or rename content, do
$ svn mv oldpath newpath $ svn ciThese commands only affect new versions of the repository tree. Old versions remain as they were. If you add a large file to the repository in error, and then svn rm it, it will still be there taking up disk space.
Subversion can become confused if structural changes are made to the repository by one person while another unknowingly edits affected files in their unsynchronised working copy. You should always inform team members in advance about structural changes, so they can check in pending changes first and pick up the new structure before doing further work.
You can view older versions of files with
$ svn cat -r N pathnameThis writes to standard output, so you can redirect it to a file. Use svn log -v pathname to choose the revision you want to look at.
To backtrack on changes you have made to files or structure in your working copy but not yet checked in, do
$ svn revert pathnameThis throws away your changes.
To revert to a particular revision, do
$ svn copy -r N http://hostname/path/to/repos/file1 ./file1 $ svn ci -m "Reverted file1 to revision N"