Difference between revisions of "SVN"

From CDOT Wiki
Jump to: navigation, search
(svn resolved)
(svn resolved)
Line 129: Line 129:
  
 
*You need to do one of three things:
 
*You need to do one of three things:
    *Merge the conflicted text “by hand” (by examining and editing the conflict markers within the file).
+
**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.
+
**Copy one of the temporary files on top of your working file.
    *Run <b>svn revert <filename></b> to throw away all of your local changes.
+
**Run <b>svn revert <filename></b> to throw away all of your local changes.
  
 
*Once you've resolved the conflict, you need to let Subversion know by running <b>svn resolved</b>. This removes the three temporary files and the file is no longer in a state of conflict:
 
*Once you've resolved the conflict, you need to let Subversion know by running <b>svn resolved</b>. This removes the three temporary files and the file is no longer in a state of conflict:

Revision as of 20:03, 22 October 2006

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:

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
$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 after you commit:
svn add filename1.c

svn delete

  • To delete file from repository and your working copy after you commit:
svn delete filename1.c

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

Resolve Conflicts (Merging Others' Changes)

svn resolved

  • You can predict conflicts by the file codes:
$ 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:

Once you've resolved the conflict, you need to let Subversion know by running svn resolved. This removes the three temporary files and Subversion no longer considers the file to be in a state of conflict.[4]

$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'

Commit your changes

svn commit

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