Work in progress!
- trunk directory - "main line" of development
- branches directory - branch copies
- tag directory - tag copies
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://cdot.senecac.on.ca/<yourprojecthere>/
Update your working copy
- 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
- To add file to repository:
svn add filename1.c
- It will be on the server after you do a commit
- 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
- 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
- item2 is scheduled for addition as a copy of item1, and item1 is scheduled for removal:
svn move item1 item2
Examine your changes
- 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.
- 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
- 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
- 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 README $ svn delete README D README $ svn revert README Reverted 'README' $ svn status README README
Merge other's changes into your working copy
Resolve Conflicts (Merging Others' Changes)
- You can predict conflicts after svn update by the file code:
$ svn update C sandwich.txt Updated to revision 46. $ ls -1 sandwich.txt sandwich.txt.mine sandwich.txt.r1 sandwich.txt.r2
- 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
- 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.
- 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: http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.diff.html
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 C:\svn\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:
MyFirstRepository/ |-conf/ |-authz |-passwd |-svnserve.conf |-dav/ |-db/ |-<bunch of subdirectories and files in here> |-hooks/ |-<bunch of files in here> |-locks/ |-<bunch of files in here> |-format |-README.txt
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.
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:
[users] user1 = password1 user2 = password2