SvnHelp >

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

  2. A conceptual introduction to SVN for CVS users.

  3. Basic commands.

  4. Moving patches around: merging and backporting.

  5. How to maintain a branch.

  6. Various tricks and recipes.

  7. Troubleshooting.

Set up and optimize SVN to access the GCC repository

How to access the GCC repository

   $ svn ls svn://gcc.gnu.org/svn/gcc
   branches/
   emptydir/
   hooks/
   tags/
   trunk/

   $ svn ls svn+ssh://username@gcc.gnu.org/svn/gcc
   branches/
   emptydir/
   hooks/
   tags/
   trunk/

If you have troubles, make sure to have specified the correct username. You can look into the CVS/Root file in a CVS working copy to check which is your exact username. You can omit the username part if your local account name is the same as on gcc.gnu.org, as ssh will then automatically supply this name, just as it does on the command line.

If the above commands work, you are ready to check out a tree and proceed with GCC development. The page about basic commands covers this information.

Optimize speed

For read/write access, GCC uses the svnserve protocol through a ssh tunnel svn+ssh:// . A similar setup was used also for CVS, but SVN suffers more from SSH handshaking time (it might estabilish multiple ssh connections even for a single command). So a simple way to speed it up is to use SSH_connection_caching (see this page for all the details).

If you can't do that for some reason, we recommend using the read-only protocol for normal work, and switch to read-write just for the time needed to do the commit. It is possible to switch any working copy from a protocol to another by using the svn switch --relocate command. For example, to switch a working copy from the svn:// protocol to the svn+ssh:// protocol, you can do:

 $ svn switch --relocate svn: svn+ssh:
 $ svn update

A different solution (which involves using a new HTTP+SSL protocol) is being worked on, and should be ready for Subversion 1.4. We'll see if it makes sense to support this.

Optimize disk usage

If you are worried about disk usage, first thing to do is making sure you are using the recommended Subversion client 1.3 (with older versions, a typical GCC working copy is much bigger).

At the time of writing, a GCC snapshot takes around 320Mb of space. With Subversion 1.3, a typical GCC working copy takes between 640Mb and 700Mb of of space (depends on the filesystem, eg. reiserfs is better than ext3). The "wasted" space is because SVN keeps a double copy of each and every file to let common operations be totally offline and thus blazingly fast svn diff svn status etc.). Subversion 1.4 will probably have a way to compress this copy so to waste less space (or disable it altogether, but you probably don't want that).

If you work only on a subset of the GCC tree (say: gfortran only), you can remove unneeded directories from the tree, saving some disk space. However, this cannot be done by simply deleting the directories (as they would get recreated next time you update the tree). The trick is to switch those directories to make them point to an empty directory in the repository (and we created /emptydir in the repository exactly for this!). For instance, to get rid of Ada in your checked out tree, you can do the following:

 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir libada
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gnattools
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gcc/ada
 $ svn switch svn+ssh://gcc.gnu.org/svn/gcc/emptydir gcc/testsuite/ada

Note: This will make switching between branches impractical, as switching to a branch will switch all subdirs in the process.

An alternative is to use the Sparse Directories feature of Subversion 1.5:

 $ svn update --set-depth empty libada
 $ svn update --set-depth empty gnattools
 $ svn update --set-depth empty gcc/ada
 $ svn update --set-depth empty gcc/testsuite/ada

Another solution to save space, if you normally have many working copies, is to use SVK. SVK is a replacement client for Subversion, which lets you do a local mirror of a subset of the repository (e.g. the last two years, or since GCC 3.3, or whatever) so that you can do many things totally offline, including commits, which can then be pushed up to the official repository. The trick is that a SVK working copy does not require the double copy of each and every source file, so it takes roughly half of the space.

Configure an external diff utility

Our patch guidelines suggest that patches be submitted using the -p option to get function names printed into the context surrounding changes. Subversion's internal diff library does not support -p so doing this requires configuring Subversion to use an external diff utility. To configure Subversion to use an external diff utility, create a file containing the diff command, and mark it as executable.

An example:

diff=/usr/bin/diff
args="-up"

exec ${diff} ${args} "$@"

Then edit ~/.subversion/config and specify this script as your diff command. Other information can be found in the tricks page.

None: SvnSetup (last edited 2013-08-23 15:39:09 by JonathanWakely)