svnCreating your work space:
The typical work cycle looks like this:
Update your working copy
svn update // repository changes subsequent to this copy (or last update) are merged into this copy.
Make changes
svn add <file | directory>
svn delete <file | directory>
svn copy <file | directory>
svn move <file | directory>
Examine your changes
svn status // shows modified, added, removed, or renamed files since last commit
svn diff // to see a unified diff output of your changes
svn revert
Merge others' changes into your working copy
svn update
svn resolved
Commit your changes
svn commit // merge my working copy into the repository, making a new version.
$ svn update
U foo.c
U bar.c
Updated to revision 2.
In this case, someone else checked in modifications to both foo.c and bar.c since the last time you updated, and Subversion has updated your working copy to include those changes.
When the server sends changes to your working copy, a letter code is displayed next to each item to let you know what actions Subversion performed to bring your working copy up-to-date:
File foo was Updated (received changes from the server).
File or directory foo was Added to your working copy.
File or directory foo was Deleted from your working copy.
File or directory foo was Replaced in your working copy: foo was deleted, and a new item with the same name was added. Subversion considers them to be distinct objects.
File foo changed in the repository, and you changed the local copy. Either the changes did not intersect, or the changes were exactly the same as your local modifications. Subversion successfully merGed the repository's changes into the file.
File foo received Conflicting changes from the server: The changes overlap your changes and need to be resolved by you; we explain how below.
M bar.c # the content in bar.c has local modifications
? foo.o # svn doesn't manage foo.o
! some_dir # svn manages this, but it's either missing or incomplete
D stuff/fish.c # this file is scheduled for deletion
A stuff/loot/bloo.h # this file is scheduled for addition
C stuff/loot/lump.c # this file has conflicts from an update
$ svn diff
Index: bar.c
===================================================================
--- bar.c (revision 3)
+++ bar.c (working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>
int main(void) {
- printf("Sixty-four slices of American Cheese...\n");
+ printf("Sixty-five slices of American Cheese...\n");
return 0;
}
Index: README
===================================================================
--- README (revision 3)
+++ README (working copy)
@@ -193,3 +193,4 @@
+Note to self: pick up laundry.
Index: stuff/fish.c
===================================================================
--- stuff/fish.c (revision 1)
+++ stuff/fish.c (working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.
Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h (revision 8)
+++ stuff/things/bloo.h (working copy)
+Here is a new file to describe
+things about bloo.
$ svn revert README
Reverted 'README'
Subversion reverts the file to its pre-modified state.
svn revert can undo any scheduled operation.
$ svn status foo
? foo
$ svn add foo
A foo
$ svn revert foo
Reverted 'foo'
$ svn status foo
? foo
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
The C stands for conflict. You have to manually choose between your changes to bar.c and those in the repository.
3 things typically occur to assist you in noticing and resolving that conflict:
Subversion prints a C during the update.
If Subversion considers the file to be mergeable (i.e., capable of line-based modification), it places conflict markers - special strings of text which delimit the "sides" of the conflict - into the file to visibly demonstrate the overlapping areas.
For every conflicted file, Subversion places up to 3 unversioned files in your working copy:
The working copy of the file before you updated it working copy - without conflict markers.
Tthe BASE revision of your working copy.
This file corresponds to the HEAD revision of the repository.
OLDREV is the revision number of the file in your .svn directory and NEWREV is the revision number of the repository HEAD.
For example, Sally changes the file sandwich.txt in the repository. Harry changes the file in his working copy and commits in. Sally updates her working copy before checking in and she gets a conflict:
$ svn update
C sandwich.txt
Updated to revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2
Subversion will not allow you to commit the file sandwich.txt until the 3 temporary files are removed.
$ svn commit --message "Add a few more things"
svn: Commit failed (details follow):
svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict
You need to either:
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 let Subversion know by running svn resolved. This removes the 3 temporary files. Subversion no longer considers the file to be in conflict.
$ svn resolved sandwich.txt
Resolved conflicted state of 'sandwich.txt'
You and Sally, both edit the file sandwich.txt at the same time. Sally commits her changes. When you update your working copy, you get a conflict. Edit sandwich.txt to resolve the conflicts.
$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread
The <<, ==, and >> are conflict markers: They are not part of the actual data in conflict. Ensure that those are removed from the file before your next commit. The text between the first 2 sets of markers is composed of the changes you made in the conflicting area:
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
The text between the 2nd and 3rd sets of conflict markers is the text from Sally's commit:
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
You talk to Sally, and do the right thing (discard Sally's edits):
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread
Run svn resolved
$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits."
If you get a conflict and decide that you want to throw out your changes, you can merely copy one of the temporary files created by Subversion over the file in your working copy:
$ svn update
C sandwich.txt
Updated to revision 2.
$ ls sandwich.*
sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1
$ cp sandwich.txt.r2 sandwich.txt
$ svn resolved sandwich.txt
If you get a conflict and want to throw out your changes, revert:
$ svn revert sandwich.txt
Reverted 'sandwich.txt'
$ ls sandwich.*
sandwich.txt
When you revert a conflicted file, you don't have to run svn resolved.
svn resolved requires an argument. Only run svn resolved when you're certain that you've fixed the conflict in your file - once the temporary files are removed, Subversion lets you commit the file even if it still contains conflict markers.
The commit operation requires a log message (describing your change). Your log message is attached to the new revision. If your log message is brief, you may supply it on the command line using the --message (or -m) option:
$ svn commit --message "Corrected number of cheese slices."
Sending sandwich.txt
Transmitting file data .
Committed revision 3.
If you are composing your log message in a separate file as you work, tell Subversion to get the message from the file:
$ svn commit --file logmsg
Sending sandwich.txt
Transmitting file data .
Committed revision 4.
If you fail to specify either the --message or --file switch, then Subversion will automatically launch your favorite editor for composing a log message.
If you get:
$ svn commit --message "Add another rule"
Sending rules.txt
svn: Commit failed (details follow):
svn: Out of date: 'rules.txt' in transaction 'g'
Run svn update, deal with any merges or conflicts that result, and re-commit.