Open main menu

CDOT Wiki β

SVN

Revision as of 14:20, 24 October 2006 by Elichak (talk | contribs) (svn resolved)

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://cdot.senecac.on.ca/<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 
       README

$ svn delete README 
D         README

$ svn revert README
Reverted 'README'

$ svn status README
       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
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

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: http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.diff.html

References