Using SVK to work with the GCC SVN repository

Everything not covered here should be covered in the SVK Book.

Setup From Tarball

First download one of the following bootstrap tarballs from gcc.gnu.org, based on your needs and the amount of disk space available:

The rest of this page assumes you are using the full "svk-all-entire-history" file. Adjust accordingly if you use one of the smaller versions, which may have a slightly different layout.

To uncompress the file you will need rzip. Packages for rzip may already be available for your distribution, or it is very easy to build. Uncompress and then untar the archive.

Set a UUID for the archive. The UUID goes in the plain text file svk/db/uuid On most GNU/Linux systems you can create a UUID by running uuidgen If not, you can make one up: a hex number with dashes, formatted as %08x-%04x-%04x-%04x-%012x.

Next use svk depotmap to tell your installed SVK where to find the depot. Point to the top level directory as unpacked, e.g. /path/to/svk The depot path should contain the db subdirectory, et cetera. Make sure you edit depotmap so that the Default Depot (empty depot name) is /path/to/svk/ for the commands shown below to work. Also, those with write access will need to relocate the depot URL with 

$ svk mirror --relocate //gcc svn+ssh://gcc.gnu.org/svn/gcc

otherwise attempts to commit to GCC upstream will result in frustration.

Setup From Scratch

If you would rather start from scratch than use a bootstrap tarball, you can do it this way.

For a basic SVK setup you need to create a SVK depotmap (if you don't have one yet) and set up a path to mirror the SVN repository from: 

$ svk depotmap
$ svk mirror //gcc svn+ssh://username@gcc.gnu.org/svn/gcc

You don't need to mirror the whole SVN repository (which would take approximately 8.5GB) but can start from any revision, including just HEAD. So for an initial sync (the svk mirror command didn't yet mirror anything), do 

$ svk sync -s HEAD //gcc

or replace HEAD with a (numerical) revision you want to start mirroring. In place of where you did cvs update in the past you now have to sync the mirror again by just doing 

$ svk sync //gcc

which will just fetch all new revisions available.

SVK takes a long time, especially on tags generated by cvs2svn. Also, up until recently (unreleased versions as of 2005-11-08 are mostly fixed) SVK also leaked memory badly mirroring GCC. But the backend is a transactional database, and SVK will cope just fine with being interrupted. So if you go into swap, you can hit C-c and then restart svk.

Working with SVK

Check-out a working copy

You can do this with 

$ svk checkout //gcc/trunk gcc

note that an SVK checkout does not place any metadata inside the working copy, but remembers the paths of working copies in a config file (in your home directory).

Starting a local branch

With SVK you can branch even for very small changes, such as fixing a PR. Coupled with svk switch this means you do not need having N check-out directories if you are waiting for N approvals!

You can create a multi-level structure of branches, just like in subversion, and then start a local branch: 

$ svk mkdir //gcc-local
$ svk mkdir //gcc-local/prs
$ svk copy //gcc //gcc-local/prs/pr19653

You can then switch to it just like to every other GCC branch. 

$ svk switch //gcc-local/prs/pr19653

The command for checking in is svk ci (nothing new). Inside a local branch, you can check in changes freely. If you commit to a mirrored path //gcc , rather than a local branch, you'll need to be able to access the path's upstream subversion server, and the commit will be sent to the server instantly.

From time to time, pull down changes from the upstream repository (this is cvs update : 

$ svk pull //gcc

When submitting one patch to mainline you have to place together the changes in a single commit: 

$ svk switch //gcc
$ svk smerge //gcc-local/prs/pr19653
$ svk push -P patch-check.diff
$ less patch-check.diff
$ svk push --lump

None: SvkHelp (last edited 2008-01-10 19:38:59 by localhost)