SvnHelp >

  1. Set up and optimize SVN to access the GCC repository.

  2. A conceptual introduction to SVN for CVS users.

  3. SVN Basic commands.

  4. Moving patches around: merging and backporting.

  5. How to maintain a branch.

  6. Various tricks and recipes.

  7. Troubleshooting.

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://
A  trunk/README
A  trunk/
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:// gcc-head-test
A  gcc-head-test/MAINTAINERS
A  gcc-head-test/README
A  gcc-head-test/
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).

Reverting changes

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.

Committing changes

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.

Resolving conflicts

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.*

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:

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.*

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://
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://
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:// | 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).

None: SvnBasic (last edited 2008-08-26 09:41:27 by ManuelLopezIbanez)