Chapter 9. SVK Complete Reference

Table of Contents

The SVK Command Line Client: svk
svk Switches
svk Subcommands
svk add
svk admin
svk annotate
svk cat
svk checkout
svk cleanup
svk cmerge
svk commit
svk copy
svk delete
svk depotmap
svk describe
svk diff
svk help
svk import
svk info
svk list
svk log
svk merge
svk mirror
svk mkdir
svk move
svk patch
svk propdel
svk propedit
svk propget
svk proplist
svk propset
svk pull
svk push
svk resolved
svk revert
svk smerge
svk status
svk switch
svk sync
svk update
svk verify
svk admin
svk admin Switches
svk admin Subcommands
svk admin create
svk admin deltify
svk admin dump
svk admin help
svk admin hotcopy
svk admin list-dblogs
svk admin list-unused-dblogs
svk admin load
svk admin lslocks
svk admin lstxns
svk admin recover
svk admin rmlocks
svk admin rmtxns
svk admin setlog
svk admin verify
svk admin rmcache

This chapter is intended to be a complete reference to using the command svk line client and all its subcommands.

The SVK Command Line Client: svk

To use the command line client, you type svk, the subcommand you wish to use [19], and any switches or targets that you wish to operate on—the switches always come after the subcommand that they apply to. There are no global switches to svk, with the exception of the --help (-h) switch, which will give you help for a particular subcommand.

To get help on how to use a command you could run any of:

$ svk -h status
$ svk --help status
$ svk status -h 
$ svk status --help                                                  
$ svk help status

One notable exception to the svk subcommand switches rule is the admin subcommand. This command takes it's own set of subcommands. It's described below in the the section called “svk admin section.

You can find examples of how to use most client commands in Chapter 3, Guided Tour and commands for managing properties in the section called “”.

svk Switches

While SVK has different switches for its subcommands, all switches are global[20]—that is, each switch is guaranteed to mean the same thing regardless of the subcommand you use it with. For example, --verbose (-v) always means “verbose output”, regardless of the subcommand you use it with.

You can specify a command line switch anywhere on the command line after the name of the subcommand itself. So it's OK to mix switches and options. SVK knows what is what.

--all (-a)

Causes SVK to operate on all instances of a particular kind. It depends on the subcommand what exactly this means.

--auto (-a)

Requests svk uses the previous merge point as the starting point for this cmerge or merge operation.

--base (-b) REV[@]

Use REV[@] as the merge base. See the --revision for an explanation of valid values for REV[@].

--baseless (-B)

Use the youngest revision as the merge base.

--change (-c) [-]REV[@]

Act on the change made by revision [-]REV[@]. Specifying an @ after the revision number will cause SVK to operate on the mirrored repository's revision number rather than the local depots revision number if the path being operated on is a mirrored path. Specifying REV is the same as --revision REV-1:REV, whereas specifying -REV is equivalent to --revision REV:REV-1.

--check-only (-C)

Goes through all the motions of running a command, but makes no actual changes—either on disk or in the depot.

--cross (-x)

Causes a SVK subcommand which is traversing the history of a versioned resource to continue harvesting that historical information when a copy—that is, a location in history where that resource was copied from another location in the repository—is encountered.


Apply the svk patch operation to the depot specified by DEPOTNAME.

--depth (-d) LEVEL

Recurse at most LEVEL levels deep. This is used together with the --recursive switch to svk list.

--detach (-d) [DEPOTPATH | PATH]

Request that SVK forget about a depot, mirror or working copy.


Commit directly even if the path is mirrored.


Don't ever use this option unless you know what you are doing. Better yet don't use this option unless your IRC handle is clkao.

--encoding ENC

Tells SVK that your commit message is encoded in the charset provided. The default is your operating system's native locale, and you should specify the encoding if your commit message is in any other encoding.


Export mode, checkout a detached copy.

--file (-F) FILENAME

Uses the contents of the file passed as an argument to this switch for the specified subcommand.

--from (-f)

Merges or pushes from the specified PATH.

--from-checkout (-f)

Allows a svk import to be run on a working copy.

--full-path (-f)

Shows the full path of listed files rather than showing files and directories as a tree.

--help (-h or -?)

If used with one or more subcommands, shows the built-in help text for each subcommand. If used alone, it displays the general client help text.

--host HOST

Use HOST as the hostname shown in the merge log.


Import mode. Automatically add any new nodes and delete any missing ones. This switch is used with the commit command. An example of how it could be used to track a third party product is:

$ svk checkout --non-recursive //thirdparty/trunk thirdparty-1.2.3
$ tar xvf thirdparty-1.2.3.tar
$ svk commit --import thirdparty-1.2.3
--incremental (-I)

Applies each change individually.

--init (-i)

Initialize the default depot.

--keep-local (-K)

Prevents svk from removing a file from a working copy when it is scheduled for deletion via svk delete.

--limit (-l) NUM

Show only the first NUM log messages.

--list (-l)

Show a list of pairs. Shows depotpath, working copy pairs with svk checkout, depotpath, mirror source pairs with svk mirror and depotname, repository path pairs with svk depotmap.

--log (-l)

Generate a commit log message consisting of all the log messages of the revision being merged.

--lump (-l)

When causes the svk push and svk pull commands to lump all the changes together in a single commit, rather than commit each change incrementally when calling svk smerge.

--merge (-m)

If the depotpath for the working copy being updated is a copy of another depotpath—i.e. a branch, perform a svk smerge --log --message '' from the original to the copy before executing the actual command.

--message (-m) MESSAGE

Indicates that you will specify a commit message on the command line, following this switch. For example:

$ svk commit --message "They don't make Sunday."
--parent (-p)

Recursively create intermediate directories in the depot as required.

--patch (-P) NAME

Rather than committing a change SVK will generate a patch named NAME. The name - will cause svk to output the patch the standard output rather than storing it.

--non-recursive (-N)

Stops a subcommand from recursing into subdirectories. Most subcommands recurse by default, but some subcommands—usually those that have the potential to remove or undo your local modifications—do not.


Do not ignore files that would normally be ignored.


Indicates that you do not with this merge point to be recorded for merge tracking purposes.

--quiet (-q)

Requests that the client print only essential information while performing an operation.


Recover the state of a mirrored depot path.

--recursive (-R)

Makes a subcommand recurse into subdirectories. Most subcommands recurse by default.

--relocate [FROM] TO

Used with the svk mirror subcommand, changes the location of the remote repository that the mirror in a local depot references. This is useful if the location of your repository changes and you have an existing mirror that you'd like to continue to use. See svk mirror for an example.

Used with the svk checkout to move a working copy to a different location.

Used with the svk depotmap to move a depot to a different location.


Makes a generated merge log use revision numbers from the remote mirror rather than those in the depot.

--revision (-r) REV[@]:[REV2[@]]

Indicates that you're going to supply a revision (or range of revisions) for a particular operation. You can provide revision numbers, revision keywords or dates (in curly braces), as arguments to the revision switch. If you wish to provide a range of revisions, you can provide two revisions separated by a colon. For example:

$ svk log --revision 1729
$ svk log --revision 1729:HEAD
$ svk log --revision 1729:1744
$ svk log --revision {2001-12-04}:{2002-02-17}
$ svk log --revision 1729:{2002-02-17}

If the path for which you specified REV is a mirrored path, you may append an @ to then end of the REV to refer to the revision number in the remote mirror rather than the one in the local depot. For example:

$ svk log --revision 1729@ //mirrors/test
$ svk log --revision 1729@:1744@

See the section called “Revision Keywords” for more information.


Operates on a revision property instead of a property specific to a file or directory. This switch requires that you also pass a revision with the --revision (-r) switch. See the section called “” for more details on unversioned properties.

--sign (-S)

Causes SVK to use sign the change being committed.

--skipto (-s) REMOTEREV

During svk sync will start mirroring from the remote repositories revision REMOTEREV, rather than the first not yet mirrored revision.


Causes SVK to use strict semantics, a notion which is rather vague unless talking about specific subcommands.

--summarize (-s)

Causes svk diff to show a status like summary of changes rather than the actual diffs.

--sync (-s)

Synchronize with mirrored sources before starting the operation.


Used together with the --message (-m) or the --file (-F) switch, it uses the specified message as a template to edit rather than as the actual commit message.

--to (-t)

Merges to the specified PATH.

--to-checkout (-t)

Request that a tree on which svk import is run be turned into a working copy immediately

--torev (-t) REMOTEREV

During svk sync will mirror up to the specified remote repositories revision REMOTEREV, rather than HEAD.


Requests that SVK track changes made to renamed nodes and do the right thing when this occurs.


Forcibly remove a stale lock on a mirror.


Upgrade a mirror to the latest version.


Produces a verbatim merge log without any indents or headers.

--verbose (-v)

Requests that the client print out as much information as it can while running any subcommand. This may result in SVK printing out additional fields, detailed information about every file, or additional information regarding its actions.


Prints the client version info.

svk Subcommands

[19] Yes, yes, you don't need a subcommand to use the --version switch, but we'll get to that in just a minute.

[20] While this true for the long versions of all switches there is some aliasing going on with the short (one letter versions) of some.