SVN

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 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

• SVN Branch Maintanance
• Basic Work Cycle