SVN Basic commands
This page explains all the basic commands of SVN which are needed for day-to-day work. This page assumes that you are a maintainer of GCC, so it uses the svn+ssh:// protocol for URLs (unless it does not matter). Make sure to read the page about SVN configuration, which explains that the svn:// protocol can be used instead if you don't have/need commit rights.
Checking out GCC
Just like in CVS, you can use svn checkout
$ svn co svn+ssh://email@example.com/svn/gcc/trunk A trunk/MAINTAINERS A trunk/README A trunk/configure.in [...] Checked out revision 56230.
By playing with the URL, you can select whether to check out the trunk, a branch, or a tag. The username is useful only during checkout: all later commands will automatically know which username to use.
By default, SVN will automatically create a directory into which the files will be checked out (using the last component of the URL: trunk in this case). If you prefer, you can specify a different name for it:
$ svn co svn+ssh://firstname.lastname@example.org/svn/gcc/trunk gcc-head-test A gcc-head-test/MAINTAINERS A gcc-head-test/README A gcc-head-test/configure.in ... Checked out revision 56230.
Updating the local copy
=svn update= works exactly like cvs update It's also smarter by default: it creates missing directories and prune empty directiores.
Finding out what's up in your working copy
The commands svn diff and svn status are similar to CVS too, but they do not require any kind of server connection: they are totally off-line operations (there is another copy of all the files within the svn metadata). Notice that the output of svn status is very similar to the output of an update, so it can used to quickly check which files were locally modified:
$ svn status M gcc/reload.c M gcc/reload1.c
and unlike an update operation, it is totally off-line. svn diff outputs only unified-diff using an internal engine, unless you configure an external diff program (see the tricks page about this).
A useful command is also svn revert which reverts the local changes, restoring the last-updated version of the files (this is an off-line operation too). Since reverting changes is a pretty dangerous operations, you'll have to always specify a target (file or directory) on the command line. Also, by default the command is non-recursive: use -R to force it. Thus, svn revert -R . from the toplevel will revert the whole tree.
To commit changes, it is sufficient to use svn commit which is very similar to cvs commit Notice that, since SVN has the notion of changesets, for a change to be considered a single changeset it is *required* to commit all the files of that changeset at the same time. This is easily done by doing svn commit at the top-level of the tree if you want it to catch all your local changes.
In SVN, the conflict status is sort of 'sticky': after a conflict is detected, SVN remembers that the file is in conflict status. Let's see an example:
$ svn up U gcc/global.c C gcc/reload.c U gcc/simplify-rtx.c Updated to revision 5624 $ ls -1 gcc/reload.* gcc/reload.c gcc/reload.c.mine gcc/reload.c.r5623 gcc/reload.c.r5624
After detecting a conflict, SVN adds the usual conflict markers to the original file gcc/reload.c , and also prepares three additional files to help in the merge process:
gcc/reload.c.mine the locally modified version before the update
gcc/reload.c.r5623 the previous version (the version against which the local changes were made)
gcc/reload.c.r5624 the new version (the version we were trying to update to)
Resolving the changes can be done by manually editing the file containing the conflict markers (as usually done), or by copying one of the three pure versions over it. After that, it is necessary to inform SVN about the fact the conflict was resolved:
$ svn status gcc/reload.c C reload.c $ cp gcc/reload.c.r5624 gcc/reload.c # revert local changes $ svn resolved gcc/reload.c Resolved conflicted state of 'gcc/reload.c' $ svn status gcc/reload.c M gcc/reload.c $ ls -1 gcc/reload.* gcc/reload.c
SVN cleans up the additional files created to help the conflict resolution leaving a clean tree, and the file is ready to be committed.
Inspecting the history
To find out when a file (or directory) was modified, you can use svn log This command (like many others) accepts both a local path or a remote URL.
$ svn log gcc/reload.c ------------------------------------------------------------------- r5635 | sayle | Fri, 8 Jul 2005 14:34:12 -0600 | 18 lines [commit message] ------------------------------------------------------------------- r5212 | rth | Fri, 1 Jul 2005 12:12:45 -0900 | 4 lines [commit message] ------------------------------------------------------------------- [...]
The log shows who modified the file, when, and the commit message (which in the GCC case will be the ChangeLog of the change). Notice again that the revision number identifies the whole tree not the single file, so it is perfectly possible for it to jump like in the example: it means that other patches not affecting gcc/reload.c went in that timeframe.
Another useful command in this regard is svn info which displays several information about the specified file or directory, including its full URL, the number of the last changeset that modified it, etc.
$ svn info Path: . URL: svn+ssh://email@example.com/svn/gcc/trunk Repository UUID: 284566a7-fc02-0410-aa54-b5c5f2f15645 Revision: 105374 Node Kind: directory Schedule: normal $ svn info gcc/java/parse-scan.y Path: gcc/java/parse-scan.y Name: parse-scan.y URL: svn+ssh://firstname.lastname@example.org/svn/gcc/trunk/gcc/java/parse-scan.y Repository UUID: 284566a7-fc02-0410-aa54-b5c5f2f15645 Revision: 105374 Node Kind: file Schedule: normal Last Changed Author: tromey Last Changed Rev: 101948 Last Changed Date: 2005-07-13 00:35:03 +0200 Text Last Updated: 2005-10-22 18:10:52 +0200 Properties Last Updated: 2005-10-22 18:10:50 +0200 Checksum: 830b1a2362ff732e7c8c47edfe3aff1d
The format is easily greppable, in case you did not notice already. svn info (like most other commands) works with URL too, so for instance it might be useful to do:
$ svn info svn://gcc.gnu.org/svn/gcc/trunk/gcc/java/parse-scan.y | grep "Last Changed" Last Changed Author: tromey Last Changed Rev: 101948 Last Changed Date: 2005-07-13 00:35:03 +0200 (Wed, 13 Jul 2005)
Copying, moving, renaming files
These operations (that were not supported in CVS) are available through svn copy and svn move The latter is done in terms of a copy plus a deletion of the old file, so the real building-block is svn copy Of course, the history of the file is maintained through the copy operation. Notice that copying files (or even whole subdirectories) is *extremely* cheap on SVN: you may think of it as a hard link of a file or a directory. (Note that when a copied file is modified, the hard link analogy is no longer accurate because both files will diverge).