Unix in a Nutshell, Fourth Edition
| < Day Day Up > |
| The syntax for the Subversion command line client, svn, is: svn [options ] subcommand [arguments] The options and subcommand may be provided in any order. 15.4.1. svn Options
While Subversion has different options for its subcommands, all options are global that is, each option is guaranteed to mean the same thing regardless of the subcommand that you use it with. For example, --verbose (-v) always means "verbose output," no matter which subcommand you use it with.
The acceptable revision keywords for --revision are:
15.4.2. svn Subcommands
The svn command is the main user interface to Subversion. It works by accepting subcommands with arguments. The general form is: svn subcommand [options] arguments
svn add path ... Add files and directories to your working copy and schedule them for addition to the repository. They will be uploaded and added to the repository on your next commit. If you add something and change your mind before committing, you can unschedule the addition using svn revert.
Options
Examples
To add a file to your working copy: $ svn add foo.c A foo.c
You can add a directory without adding its contents: $ svn add --non-recursive otherdir A otherdir
svn blame target ... Show author and revision information in-line for the specified files or URLs. Each line of text is annotated at the beginning with the author (username) and the revision number for the last change to that line.
Options
svn cat target ... Output the contents of the specified files or URLs. For listing the contents of directories, see svn list.
Options
Examples
To view readme.txt in your repository without checking it out: $ svn cat http://svn.red-bean.com/repos/test/readme.txt This is a README file. You should read this.
svn checkout URL ... [path]
Check out a working copy from a repository. If path is omitted, the basename of the URL is used as the destination. If multiple URLs are given, each one is checked out into a subdirectory of path, with the name of the subdirectory being the basename of the URL.
Options
Examples
Check out a working copy into a directory called mine: $ svn checkout file:///tmp/repos/test mine A mine/a A mine/b Checked out revision 2. $ ls mine
If you interrupt a checkout (or something else interrupts your checkout like loss of connectivity, etc.), you can restart it either by issuing the identical checkout command again, or by updating the incomplete working copy: $ svn checkout file:///tmp/repos/test test A test/a A test/b ^C svn: The operation was interrupted svn: caught SIGINT $ svn checkout file:///tmp/repos/test test A test/c A test/d ^C svn: The operation was interrupted svn: caught SIGINT $ cd test $ svn update A test/e A test/f Updated to revision 3.
svn cleanup [path ...]
Recursively clean up the working copy, removing locks and resuming unfinished operations. If you ever get a "working copy locked" error, run this command to remove stale locks and get your working copy into a usable state again. If, for some reason, an svn update fails due to a problem running an external diff program (e.g., user input or network failure), pass the --diff3-cmd option to allow cleanup to complete any merging with your external diff program. You can also specify any configuration directory with the --config-dir option, but you should rarely need these options.
Options:
svn commit [path ...] Send changes from your working copy to the repository. If you don't supply a log message with your commit by using either the --file or --message option, svn starts your editor for you to compose a commit message.
Options
Examples
Commit a simple modification to a file with the commit message on the command line and an implicit target of your current directory ("."): $ svn commit -m "added howto section." Sending a Transmitting file data . Committed revision 3. To commit a file scheduled for deletion: $ svn commit -m "removed file 'c'." Deleting c Committed revision 7.
svn copy src dst
Copy a file in a working copy or in the repository. src and dst can each be either a working copy (WC) path or a URL:
Options
Examples
Copy an item within your working copy (just schedule the copy nothing goes into the repository until you commit): $ svn copy foo.txt bar.txt A bar.txt $ svn status A + bar.txt
Copy an item from the repository to your working copy (just schedule the copy nothing goes into the repository until you commit): $ svn copy file:///tmp/repos/test/far-away near-here A near-here
And finally, copying between two URLs: $ svn copy file:///tmp/repos/test/far-away \ > file:///tmp/repos/test/over-there -m "remote copy." Committed revision 9.
$ svn copy file:///tmp/repos/test/trunk \ > file:///tmp/repos/test/tags/0.6.32-prerelease \ > -m "tag tree" Committed revision 12.
svn delete path ... svn delete URL ... Items specified by path are scheduled for deletion upon the next commit. Files (and directories that have not been committed) are immediately removed from the working copy. The command will not remove any unversioned or modified items; use the --force option to override this behavior. Items specified by URL are deleted from the repository via an immediate commit. Multiple URLs are committed atomically.
Options
svn diff [-r N[:M]] [--old old-tgt][--new new-tgt] [path ...] svn diff -r N:M URLsvn diff [-r N[:M]] URL1[@N] URL2[@M]
Display the differences between two paths. The three different ways you can use svn diff are:
If target is a URL, then revisions N and M can be given either via the --revision option or by using "@" notation as described earlier. If target is a working copy path, then the --revision option means:
If the alternate syntax is used, the server compares URL1 and URL2 at revisions N and M respectively. If either N or M are omitted, a value of HEAD is assumed. By default, svn diff ignores the ancestry of files and merely compares the contents of the two files being compared. If you use --notice-ancestry, the ancestry of the paths in question is taken into consideration when comparing revisions (that is, if you run svn diff on two files with identical contents but different ancestry you will see the entire contents of the file as having been removed and added again).
Options
Examples
Compare BASE and your working copy: $ svn diff COMMITTERS Index: COMMITTERS ========================================================== --- COMMITTERS (revision 4404) +++ COMMITTERS (working copy) ... See how your working copy's modifications compare against an older revision: $ svn diff -r 3900 COMMITTERS Index: COMMITTERS ========================================================== --- COMMITTERS (revision 3900) +++ COMMITTERS (working copy) ...
Use --diff-cmd cmd and -x to pass arguments directly to the external diff program: $ svn diff --diff-cmd /usr/bin/diff -x "-i -b" COMMITTERS Index: COMMITTERS ========================================================== 0a1,2 > This is a test >
svn export [-r rev] URL [path] svn export path1 path2
The first form exports a clean directory tree from the repository specified by URL (at revision rev if it is given, otherwise at HEAD) into path. If path is omitted, the last component of the URL is used for the local directory name. The second form exports a clean directory tree from the working copy specified by path1 into path2. All local changes are preserved, but files not under version control are not copied.
Options
svn help [subcommand ...] Provide a quick usage summary. With subcommand, provide information about the given subcommand.
Options
svn import [path] URL Recursively commit a copy of path to URL. If path is omitted "." is assumed. Parent directories are created in the repository as necessary.
Options
Examples
Import the local directory myproj into the root of your repository: $ svn import -m "New import" myproj \ > http://svn.red-bean.com/repos/test Adding myproj/sample.txt ... Transmitting file data ......... Committed revision 16. Import the local directory myproj into trunk/vendors in your repository. The directory trunk/vendors need not exist before you import into it--svn import will recursively create directories for you: $ svn import -m "New import" myproj \ > http://svn.red-bean.com/repos/test/trunk/vendors/myproj Adding myproj/sample.txt ... Transmitting file data ......... Committed revision 19.
After importing data, note that the original tree is not under version control. To start working, you still need to svn checkout a fresh working copy of the tree.
svn info [path ...] Print information about paths in your working copy, including:
Options
svn list [target ...] List each target file and the contents of each target directory as they exist in the repository. If target is a working copy path, the corresponding repository URL is used. The default target is ".", meaning the repository URL of the current working copy directory. With --verbose, the following fields show the status of the item:
Options
Examples
To see what files a repository has without downloading a working copy: $ svn list http://svn.red-bean.com/repos/test/support README.txt INSTALL examples/ ... Pass the --verbose option for additional information: $ svn list --verbose file:///tmp/repos 16 sue 28361 Jan 16 23:18 README.txt 27 sue 0 Jan 18 15:27 INSTALL 24 joe Jan 18 11:27 examples/
svn log [path] svn log URL [path ...] The default target is the path of your current directory. If no arguments are supplied, svn log shows the log messages for all files and directories inside of (and including) the current working directory of your working copy. You can refine the results by specifying a path, one or more revisions, or any combination of the two. The default revision range for a local path is BASE:1. If you specify a URL alone, svn log prints log messages for everything that the URL contains. If you add paths past the URL, only messages for those paths under that URL are printed. The default revision range for a URL is HEAD:1. With --verbose, svn log also prints all affected paths with each log message. With --quiet, svn log does not print the log message body itself (this is compatible with --verbose). Each log message is printed just once, even if more than one of the affected paths for that revision were explicitly requested. Logs follow copy history by default. Use --stop-on-copy to disable this behavior, which can be useful for determining branch points.
Options
Examples
To see the log messages for all the paths that changed in your working copy, run svn log from the top (some long output lines have wrapped): $ svn log ------------------------------------------------------------------- r20 | joe | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 line Tweak. ------------------------------------------------------------------- r17 | sue | 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003) | 2 lines ... If you don't have a working copy handy, you can log a URL: $ svn log http://svn.red-bean.com/repos/test/foo.c ------------------------------------------------------------------- r32 | sue | 2003-01-13 00:43:13 -0600 (Mon, 13 Jan 2003) | 1 line Added defines. ------------------------------------------------------------------- r28 | sue | 2003-01-07 21:48:33 -0600 (Tue, 07 Jan 2003) | 3 lines ...
svn merge sourceURL1[@N] sourceURL2[@M] [wcpath] svn merge -r N:M source [path] In the first form, the source URLs are specified at revisions N and M. These are the two sources to be compared. The revisions default to HEAD if omitted. In the second form, source can be a URL or working copy item, in which case the corresponding URL is used. This URL, at revisions N and M, defines the two sources to be compared. wcpath is the working copy path that will receive the changes. If wcpath is omitted, a default value of "." is assumed, unless the sources have identical basenames that match a file within ".", in which case, the differences are applied to that file. Unlike svn diff, this command takes the ancestry of a file into consideration when performing a merge operation. This is very important when you're merging changes from one branch into another and you've renamed a file on one branch but not the other.
Options
Examples
Merge a branch back into the trunk (assuming that you have a working copy of the trunk, and that the branch was created in revision 250): $ svn merge -r 250:HEAD \ > http://svn.red-bean.com/repos/branches/my-branch U myproj/tiny.txt U myproj/thhgttg.txt U myproj/win.txt U myproj/flo.txt
If you branched at revision 23, and you want to merge changes from the trunk into your branch, you could do this from inside the working copy of your branch: $ svn merge -r 23:30 file:///tmp/repos/trunk/vendors U myproj/thhgttg.txt ...
To merge changes to a single file: $ cd myproj $ svn merge -r 30:31 thhgttg.txt U thhgttg.txt
svn mkdir path ... svn mkdir URL ... Create a directory with a name given by the final component of the path or URL. A directory specified by a working copy path is scheduled for addition in the working copy. A directory specified by a URL is created in the repository via an immediate commit. Multiple directory URLs are committed atomically. In both cases all the intermediate directories must already exist.
Options
svn move src dst This command moves (renames) a file or directory in your working copy or in the repository.
Options
svn propdel propname [path ...] svn propdel propname --revprop -r rev [URL]
This removes properties from files, directories, or revisions. The first form removes versioned properties in your working copy, whereas the second removes unversioned remote properties on a repository revision.
Options
Examples
Delete a property from a file in your working copy: $ svn propdel svn:mime-type some-script property 'svn:mime-type' deleted from 'some-script'.
Delete a revision property: $ svn propdel --revprop -r 26 release-date property 'release-date' deleted from repository revision '26'
svn propedit propname path ... svn propedit propname --revprop -r rev [URL]
Edit one or more properties using your favorite editor. The first form edits versioned properties in your working copy, while the second edits unversioned remote properties on a repository revision.
Options
svn propget propname [path ...] svn propget propname --revprop -r rev [URL]
Print the value of a property on files, directories, or revisions. The first form prints the versioned property of an item or items in your working copy, while the second prints the unversioned remote property on a repository revision.
Options
svn proplist propname [path ...] svn proplist propname --revprop -r rev [URL]
List all properties on files, directories, or revisions. The first form lists versioned properties in your working copy, while the second lists unversioned remote properties on a repository revision.
Options
Examples
You can use svn proplist to see the properties on an item in your working copy: $ svn proplist foo.c Properties on 'foo.c': svn:mime-type svn:keywords owner
But with the --verbose flag, svn proplist is extremely handy as it also shows you the values for the properties: $ svn proplist --verbose foo.c Properties on 'foo.c': svn:mime-type : text/plain svn:keywords : Author Date Rev owner : sue
svn propset propname [propval] path ... svn propset propname --revprop -r rev [propval] [URL] Set propname to propval on files, directories, or revisions. The first example creates a versioned, local property change in the working copy, and the second creates an unversioned, remote property change on a repository revision. The new property value, propval, may be provided literally, or using the -F valfile option.
Options
Examples
Set the mimetype on a file: $ svn propset svn:mime-type image/jpeg foo.jpg property 'svn:mime-type' set on 'foo.jpg' On a Unix system, if you want a file to have execute permission: $ svn propset svn:executable ON somescript property 'svn:executable' set on 'somescript'
svn resolved path ... Remove the "conflicted" state on working copy files or directories. This command does not semantically resolve conflict markers; it merely removes conflict-related artifact files and allows path to be committed again; that is, it tells Subversion that the conflicts have been "resolved." Use it after you have resolved the conflict in the file.
Options
Example
If you get a conflict on an update, your working copy will contain three additional files: $ svn update C foo.c Updated to revision 31. $ ls foo.c Merged version with conflict markers foo.c.mine Original working copy version foo.c.r30 Unmodified BASE version foo.c.r31 Unmodified HEAD version
Once you've resolved the conflict and foo.c is ready to be committed, run svn resolved to let your working copy know you've taken care of everything.
svn revert path ...
Revert any local changes to a file or directory and resolve any conflicted states. svn revert not only reverts the contents of an item in your working copy, but also any property changes. Finally, you can use it to undo any scheduling operations that you may have done (e.g., files scheduled for addition or deletion can be "unscheduled").
Options
Examples
Discard changes to a file: $ svn revert foo.c Reverted foo.c
If you want to revert a whole directory of files, use the --recursive flag: $ svn revert --recursive . Reverted newdir/afile Reverted foo.c Reverted bar.txt
svn status [path ...]
Print the status of working copy files and directories. With no arguments, print only locally modified items (no repository access). With --show-updates, add working revision and server out-of-date information. With --verbose, print full revision information on every item. The first five columns in the output are each one character wide, and each column gives you information about different aspects of each working copy item. The first column indicates that an item was added, deleted, or otherwise changed:
The second column tells the status of a file's or directory's properties:
The third column is populated only if the working copy directory is locked:
The fourth column is populated only if the item is scheduled for addition-with-history:
The fifth column is populated only if the item is switched relative to its parent:
If you pass the --show-updates option, the out-of-date information appears in the eighth column:
The remaining fields are variable width and delimited by spaces. The working revision is the next field if the --show-updates or --verbose options are passed. If the --verbose option is passed, the last committed revision and last committed author are displayed next. The working copy path is always the final field, so it can include spaces.
Options
Examples
To find out what changes you have made to your working copy: $ svn status wc M wc/bar.c A + wc/qax.c
To find out what files in your working copy are out-of-date, pass the --show-updates option (this does not make any changes to your working copy). Here you can see that wc/foo.c has changed in the repository since we last updated our working copy: $ svn status --show-updates wc M 965 wc/bar.c * 965 wc/foo.c A + 965 wc/qax.c Status against revision: 981
And finally, the most information you can get out of the status subcommand: $ svn status --show-updates --verbose wc M 965 938 sue wc/bar.c * 965 922 joe wc/foo.c A + 965 687 joe wc/qax.c 965 687 joe wc/zig.c Head revision: 981
svn switch URL [path]
This subcommand updates your working copy to mirror a new URL usually a URL that shares a common ancestor with your working copy, although not necessarily. This is the Subversion way to move a working copy to a new branch.
Options
Examples
If you're currently inside the directory vendors, which was branched to fixed, and you'd like to switch your working copy to that branch: $ svn switch http://svn.red-bean.com/repos/branches/fixed . U myproj/foo.txt U myproj/bar.txt U myproj/baz.c U myproj/qux.c Updated to revision 31.
And to switch back, just provide the URL to the location in the repository from which you originally checked out your working copy: $ svn switch http://svn.red-bean.com/repos/trunk/vendors . U myproj/foo.txt U myproj/bar.txt U myproj/baz.c U myproj/qux.c Updated to revision 31.
Sometimes an administrator might change the "base location" of your repository in other words, the contents of the repository doesn't change, but the main URL used to reach the root of the repository does. For example, the hostname may change, or the URL schema, or perhaps just the path that leads to the repository. Rather than check out a new working copy, you can have the svn switch command "rewrite" the beginnings of all the URLs in your working copy. Use the --relocate command to do the substitution. No file contents are changed, nor is the repository contacted. It's similar to running a sed script over your working copy .svn/ directories that runs s/OldRoot/NewRoot/. $ cd /tmp $ svn checkout file:///tmp/repos test A test/a A test/b ... $ mv repos newlocation $ cd test/ $ svn update svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///tmp/repos' $ svn switch --relocate \ > file:///tmp/repos file:///tmp/newlocation . $ svn update At revision 3.
svn update [PATH ...]
svn update brings changes from the repository into your working copy. If no revision is given, it brings your working copy up-to-date with the HEAD revision. Otherwise, it synchronizes the working copy to the revision given by the --revision option. For each updated item, Subversion prints a line starting with a specific character reporting the action taken. These characters have the following meaning:
A character in the first column signifies an update to the actual file, while updates to the file's properties are shown in the second column.
Options
|
| < Day Day Up > |