You'll probably use the svk status command more than any other SVK command.

If you run svk status at the top of your working copy with no arguments, it will detect all file and tree changes you've made. Below are examples of the different status codes that svk status can return. (Note that the text following # is not actually printed by svk status.)

M   bar.c               # the content in bar.c has local modifications
 M  baz.c               # baz.c has property but no content modifications
?   foo.o               # svk doesn't manage foo.o
!   some_dir            # svk manages this, but it's missing or incomplete
~   qux                 # versioned as file/dir/link, but type has changed
I   .screenrc           # svk doesn't manage this, and is set to ignore it
A + moved_dir           # added with history of where it came from
M + moved_dir/README    # added with history and has local modifications
D   stuff/fish.c        # file is scheduled for deletion
A   stuff/loot/bloo.h   # file is scheduled for addition
C   stuff/loot/lump.c   # file has textual conflicts from an update
 C  stuff/loot/glub.c   # file has property conflicts from an update
R   xyz.c               # file is scheduled for replacement

In this output format svk status prints three columns of characters, followed by a whitespace character, followed by a file or directory name. The first column tells the status of a file or directory and/or its contents. The codes printed here are:

The second column tells the status of a file or directory's properties (see the section called “” for more information on properties). If an M appears in the second column, then the properties have been modified, otherwise a whitespace will be printed.

The third column will only show whitespace or a + which means that the file or directory is scheduled to be added or modified with additional attached history. This typically happens when you svk move or svk copy a file or directory. If you see A  +, this means the item is scheduled for addition-with-history. It could be a file, or the root of a copied directory. + means the item is part of a subtree scheduled for addition-with-history, i.e. some parent got copied, and it's just coming along for the ride. M  + means the item is part of a subtree scheduled for addition-with-history, and it has local modifications. When you commit, first the parent will be added-with-history (copied), which means this file will automatically exist in the copy. Then the local modifications will be uploaded into the copy.

If you pass a specific path to svk status, it gives you information about that item alone:

$ svk status stuff/fish.c
D   stuff/fish.c

svk status also has a --verbose (-v) switch, which will show you the status of every item in your working copy, even if it has not been changed:

$ svk status --verbose
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

This is the “long form” output of svk status. The first column remains the same, but the second column shows the working-revision of the item. The third and fourth columns show the revision in which the item last changed, and who changed it.

None of the above invocations to svk status show you changes in the depot that your working copy does not yet have. To do this you need to use the svk update with the --check-only (-C) switch, which will show what would happen if you actually ran svk update:

$ svk update --check-only
Syncing //mirror/fish/trunk(/mirror/fish/trunk) in /Users/sally/svk to 35.
C   README
U   stuff/trout.c
1 conflict found.

Notice the two entries. svk update at this point, you would receive changes to README and trout.c. This tells you some very useful information—you'll need to update and get the server changes on README before you commit, or the depot will reject your commit for being out-of-date. (More on this subject later.)

Another way to examine your changes is with the svk diff command. You can find out exactly how you've modified things by running svk diff with no arguments, which prints out file changes in unified diff format:^[9]

$ svk diff
=== bar.c
==================================================================
--- bar.c	(revision 3)
+++ bar.c	(local)
@@ -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;
 }

=== README
==================================================================
--- README	(revision 3)
+++ README	(local)
@@ -193,3 +193,4 @@ 
+Note to self:  pick up laundry.

=== stuff/fish.c
==================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(local)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

=== stuff/things/bloo.h
==================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(local)
+Here is a new file to describe
+things about bloo.

The svk diff command produces this output by comparing your working files against the BASE revision in the depot. Files scheduled for addition are displayed as all added-text, and files scheduled for deletion are displayed as all deleted text.

Output is displayed in unified diff format. That is, removed lines are prefaced with a - and added lines are prefaced with a +. svk diff also prints filename and offset information useful to the patch program, so you can generate “patches” by redirecting the diff output to a file:

$ svk diff > patchfile

You could, for example, email the patch file to another developer for review or testing prior to commit.

$ svk commit --message '' --patch - > patchfile

Now suppose you see the above diff output, and realize that your changes to README are a mistake; perhaps you accidentally typed that text into the wrong file in your editor.

This is a perfect opportunity to use svk revert.

$ svk revert README
Reverted README

SVK reverts the file to its pre-modified state by overwriting it with the version your working copy was based on. But also note that svk revert can undo any scheduled operations—for example, you might decide that you don't want to add a new file after all:

$ svk status foo
?   foo

$ svk add foo
A   foo

$ svk revert foo
Reverted foo

$ svk status foo
?   foo

Or perhaps you mistakenly removed a file from version control:

$ svk status README 
$ svk delete README 
D   README
$ svk revert README
Reverted README
$ svk status README

Merging conflicts by hand can be quite intimidating the first time you attempt it, but with a little practice, it can become as easy as falling off a bike.

Here's an example. Due to a miscommunication, you and Sally, your collaborator, both edit the file sandwich.txt at the same time. Sally commits her changes, and when you go to update your working copy, you get a conflict and we're going to have to edit sandwich.txt to resolve the conflicts. First, let's take a look at the file:

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
>>>> YOUR VERSION sandwich.txt 112646405792039
Salami
Mortadella
Prosciutto
Djon Mustard
==== ORIGINAL VERSION sandwich.txt 112646405792039
Provolone
Creole Mustard
==== THEIR VERSION sandwich.txt 112646405792039
Provolone
Sauerkraut
Grilled Chicken
Creole Mustard
<<<< 112646405792039
Bottom piece of bread

The lines ending in 112646405792039^[11] are conflict markers, and are not part of the actual data in conflict. You generally want to ensure that those are removed from the file before your next commit. The text between the first two sets of markers is composed of the changes you made in the conflicting area:

>>>> YOUR VERSION sandwich.txt 112646405792039
Salami
Mortadella
Prosciutto
Djon Mustard
==== ORIGINAL VERSION sandwich.txt 112646405792039

The text between the second and third sets of conflict markers (if any) is the text from the original revision of the file that both your working copy and Sally's version were based on:

==== ORIGINAL VERSION sandwich.txt 112646405792039
Provolone
Creole Mustard
==== THEIR VERSION sandwich.txt 112646405792039

The text between the third and fourth sets of conflict markers is the text from Sally's commit:

==== THEIR VERSION sandwich.txt 112646405792039
Provolone
Sauerkraut
Grilled Chicken
Creole Mustard
<<<< 112646405792039

Usually you won't want to just delete the conflict markers and Sally's changes—she's going to be awfully surprised when the sandwich arrives and it's not what she wanted. So this is where you pick up the phone or walk across the office and explain to Sally that you can't get sauerkraut from an Italian deli.^[12] Once you've agreed on the changes you will check in, edit your file and remove the conflict markers.

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Grilled Chicken
Djon Mustard
Bottom piece of bread

Now run svk resolved, and you're ready to commit your changes:

$ svk resolved sandwich.txt
$ svk commit -m "Go ahead and use my sandwich, discarding Sally's Sauerkraut."

If you get a conflict and you want to resolve it right away you can choose the edit option to edit the file in conflict. SVK will launch your selected editor with a buffer containing the exact same contents you would have gotten if you used the skip option above. Once you finish editing the file and all the conflict markers have been removed SVK will allow you to accept the changes you made:

$ svk update
Syncing //bread/trunk(/bread/trunk) in /Users/sally/bread to 70.
Conflict found in sandwich.txt:
e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] e
Waiting for editor...
Merged sandwich.txt:
a)ccept, e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [a] a
G   sandwich.txt

If you get a conflict and decide that you want to throw out your changes, you can merely select the theirs option when ask to resolve the conflict:

$ svk update
Syncing //bread/trunk(/bread/trunk) in /Users/sally/bread to 70.
Conflict found in sandwich.txt:
e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] t
G   sandwich.txt

If you get a conflict and decide that you want to discard the changes someone else has made to a file you have modified, you can merely select the yours option when ask to resolve the conflict:

$ svk update
Syncing //bread/trunk(/bread/trunk) in /Users/sally/bread to 70.
Conflict found in sandwich.txt:
e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] y
G   sandwich.txt

It's rare that you would do this blindly (since you don't know what the changes are that you are discarding) so in most cases you'd want to look at the changes first. To do so you would use dt to show their changes:

$ svk update
Syncing //bread/trunk(/bread/trunk) in /Users/sally/bread to 70.
Conflict found in sandwich.txt:
e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] dt
--- sandwich.txt (BASE)
+++ sandwich.txt (THEIRS)
@@ -3,5 +3,7 @@
 Lettuce
 Tomato
 Provolone
+Sauerkraut
+Grilled Chicken
 Creole Mustard
 Bottom piece of bread
Conflict found in sandwich.txt:
e)dit, d)iff, m)erge, s)kip, t)heirs, y)ours, h)elp? [e] y
G   sandwich.txt

If you get a conflict, and upon examination decide that you want to throw out your changes and start your edits again, just revert your changes:

$ svk revert sandwich.txt
Reverted 'sandwich.txt'

Note that when you revert a conflicted file, you don't have to run svk resolved.