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:
svk-all-entire-history.tar.rz (626MB compressed, 11GB uncompressed) - contains the complete history and all branches as of 2005-11-07
svk-trunk-entire-history.tar.rz (224MB compressed, ?.?GB uncompressed) - contains the trunk only, with complete history
svk-trunk-3.4-onward.tar.rz (109MB compressed, ?.?GB uncompressed) - contains the trunk only, and history only back to 3.4
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://firstname.lastname@example.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
--lump is abbreviated to minus-ell . This sequence includes the double checking of what you're going to commit. svk push --lump includes a commit operation.