From CDOT Wiki
Jump to: navigation, search

Work in progress!

Branch Maintenance

Repository layout:

  • trunk directory - "main line" of development
  • branches directory - branch copies
  • tag directory - tag copies

SVN commands

The typical work cycle will use the following commands:

Check out your project

  • To check out svn repository for your project, use the following command (do this once per client computer):
svn checkout svn://<yourprojecthere>/

Update your working copy

svn update

When working on a project with a team, you'll want to update your working copy to receive changes made by other developers since your last update. (An update will take files/directories etc. on the server and copy it to your local copy):
$svn update
U  filename1.c
U  filename2.c
Updated to revision 2.
U <filename> - file was updated (received changes from the server)

Make changes to your working copy

svn add

  • To add file to repository:
svn add filename1.c
It will be on the server after you do a commit

svn delete

  • To delete file from repository and your working copy:
svn delete filename1.c
It will be gone from the server after you do a commit

svn copy

  • To create item2 as a duplicate of item1. When item2 is added to the repository on the next commit, its copy history is recorded:
svn copy item1 item2

svn move

  • item2 is scheduled for addition as a copy of item1, and item1 is scheduled for removal:
svn move item1 item2

Examine your changes

svn status

  • After you've made changes, it's a good idea to take a look at exactly what you've changed before committing them to the repository.
$svn status
This will detect all file and tree changes you've made

  • By passing a specific path, you will get information about that item alone:
$svn status stuff/filename3.c
D    stuff/filename3.c
D <filename/directory> - File or directory was deleted from your working copy
A <filename/directory> - File or directory was added to your working copy
R <filename/directory> - File or directory was replaces in your working copy
G <filename> - File received new changes from repository but your local copy of the file had your modifications
C <filename> - File received conflicting changes from the server

  • To show the status of every item in your working copy:
$ svn status --verbose

svn diff

  • To find exactly how you've modified things, use this command (prints out file changes in unified diff format):
$ svn diff
unified diff format - removed lines are prefaced with a "-" and added line are prefaced with a "+".
  • You can generate patches by redirecting the diff output to a file (prints filename and offset information useful to the patch program:
$svn diff > patchfile

svn revert

  • To revert/undo file into its pre-modified state:
$ svn revert README
Reverted 'README'
  • You can also undo any operations:
$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Reverted 'foo'

$ svn status foo
?      foo
  • If you mistakenly removed a file from version control, you can undo it like this:
$ svn status README 

$ svn delete README 
D         README

$ svn revert README
Reverted 'README'

$ svn status README

Merge other's changes into your working copy

svn update

See this

Resolve Conflicts (Merging Others' Changes)

svn resolved

  • You can predict conflicts after svn update by the file code:
$ svn update
C  sandwich.txt
Updated to revision 46.
$ ls -1
C in front of a filename stands for conflict. Changes from the server overlapped with your own.
For every conflicted file, subversion places up to 3 extra unversionfiles in your working copy (sandwich.txt.mine, sandwich.txt.r1, sandwich.txt.r2)
  • At this point, Subversion will not allow you to commit the file sandwich.txt until the three temporary files are removed.
  • You need to do one of three things:
    • Merge the conflicted text “by hand” (by examining and editing the conflict markers within the file).
    • Copy one of the temporary files on top of your working file.
    • Run svn revert <filename> to throw away all of your local changes.
  • Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and the file is no longer in a state of conflict:
$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

Commit your changes

svn commit

  • This command sends all of your changes to the repository (takes changes in your local copy and copy them to the server). When you commit a change, you need to supply a log message, describing your change.
$ svn commit --message "Corrected number of cheese slices."
Sending        sandwich.txt
Transmitting file data .
Committed revision 3.
  • If you've been composing your log message as you work, pass the filename that contains your message with the --file switch:
$ svn commit --file logmsg 
Sending        sandwich.txt
Transmitting file data .
Committed revision 4.

More commands

  • Compare changes from one revision to another:
svn diff --revision 1:4 filename1.cpp
This example allows us to see what's changed between the first and fourth revision of the filename1.cpp file.
For a complete guide:

Create SVN Repositories on Local Machine

Because I struggled way too much to figure this out (possibly because I couldn't access the SVN book when i wanted to figure out how to do this), here is a quick rundown on how to create SVN repositories on the local machine.

Prerequisites? Subversion obviously...

It is probably a good idea to have a centralized area to house all of the repositories that you may want to create, so first you must do that. For me (and for the purposes of this guide), I will house all of the repositories in the directory: C:\svn\repositories. So here's some commands you can use to create the directory structure:

   > cd C:\
C:\> mkdir svn
C:\svn> cd svn
C:\svn> mkdir repositories
C:\svn> cd repositories

OK. Now it's time to create your repository. Let's say you want to create a repository called MyFirstRepository. You can do that by executing this command:

C:\svn\repositories> svnadmin create MyFirstRepository

That command creates a new repository that is initially empty and starts at revision 0. In the repositories directory, you should now see a directory called MyFirstRepository. If you change to this directory, you should see a directory structure similar to this:

     |-<bunch of subdirectories and files in here>
     |-<bunch of files in here>
     |-<bunch of files in here>

Now, you have two options (that I know of):

  • Checkout the repository
  • Import an existing project to that new repository

Checkout the repository

For the purposes of this part of the guide, let's say you want to checkout the repository to the desktop ergo your present working directory is the Desktop (i.e.: C:\Documents and Settings\[Username]\Desktop). To do this, issue this command:

> svn checkout file:///C:/svn/repositories/MyFirstRepository/

This will checkout the repository. You should now see a folder called MyFirstRepository on the Desktop. Note the 3 forward slashes that qualify the protocol name and forward slashes between directories.

As stated before, it is a good idea to structure your repository to have different folders for branches, tags, and the trunk. So, assuming your present working directory is the Desktop, to set up the repository structure, do something like this:

> cd MyFirstRepository
> mkdir branches tags trunk
> svn add *
> svn commit -m "set up repository structure"

Import an existing project to that new repository

For the purposes of this part of the guide, let's say you have a project located in C:\project that you want to add to the SVN repository MyFirstRepository. Here's how you can do that:

> svn import "C:\project" "file:///C:/svn/repositories/MyFirstRepository" -m "import project to repository"

This command should add everything in C:\project to the repository and commit the changes. Now, you can checkout the repository using the command:

> svn checkout file:///C:/svn/repositories/MyFirstRepository/

and you will see all of the project files you imported beforehand being checked out.

Notes: If there are spaces in the repository path or name, or path to project, you may need to enclose it in quotes for the commands to work. Thus, it is better if there are no spaces in the names and paths.

Additional Information

If you want to control access to the repository, specify the users that can access a repository, there are a couple of configuration files located in the conf directory that you can edit.


The first one, svnserve.conf, has a couple of options that you can uncomment to control access to the repository. They are:

anon-access = read  # anonymous users may have read access to the repository
auth-access = write # authenticated users may have write access to the repository
                    # a third option, none, means they have no access to the repository

password-db = passwd # Specify the location of the password database file. 
                     # This file lists the name and password for each user of the repository

authz-db = authz # Specifies the location of the authorization rules file.
                 # This file is used to define access permissions for individual users of the repository.

All of these options are commented out by default.


This file houses a list of names and passwords for each user of the repository. An example passwd file may look like this:

user1 = password1
user2 = password2