Difference between revisions of "SVN"
(→svn commit) |
|||
Line 142: | Line 142: | ||
==Commit your changes== | ==Commit your changes== | ||
===svn commit=== | ===svn commit=== | ||
+ | |||
+ | *This command sends all of your changes to the repository. When you commit a change, <b>you need to supply a log message</b>, describing your change. | ||
+ | <pre> | ||
+ | $ svn commit --message "Corrected number of cheese slices." | ||
+ | Sending sandwich.txt | ||
+ | Transmitting file data . | ||
+ | Committed revision 3. | ||
+ | </pre> | ||
+ | |||
+ | *If you've been composing your log message as you work, pass the filename that contains your message with the --file switch: | ||
+ | <pre> | ||
+ | $ svn commit --file logmsg | ||
+ | Sending sandwich.txt | ||
+ | Transmitting file data . | ||
+ | Committed revision 4. | ||
+ | </pre> | ||
==More commands== | ==More commands== |
Revision as of 20:17, 22 October 2006
Work in progress!
Contents
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 use the command commit:
svn add filename1.c
svn delete
- To delete file from repository and your working copy after you use the command 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 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. 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