You are here: Foswiki>AGLT2 Web>Subversion (22 Feb 2011, TomRockwell)Edit Attach


Subversion is a software revision control system designed to be an improvement on CVS. It generally replicates the features of CVS.



  • Mac OSX 10.5.6 uses version 1.4.4
  • Mac OSX 10.6 uses 1.6.5
  • SLC 4.5 (ROCKS 4.3 cluster) used version 1.4.4
  • SL5 (ROCKS 5.3 cluster) has 1.5.5

Ben's Notes

Made a change in site-profiles/4.2.1?

In directory site-profiles: svn commit -m "some relevant log message" (as root - and i think actually this works from any subdir too)

You have to type password twice. Sorry. Will put key forwarding in place ASAP. (this is done)

At UM, you really only need that. Edit, commit, done. Explore other things as you please. Your edits broke Rocks? Revert to the previous revision. Do a diff between that one and your working one if you have no idea what you changed. Cool. See next section about diffing.

To checkout:

svn co svn+ssh://

this will checkout into a dir called 4.2.1.

MSU: import your files into a 4.3 directory. Follow these directions: cd into site-profiles svn co svn+ssh:// . (this will co the 4.2.1 directory. You can delete it) svn add 4.3/* (see if this recurses for you and gets the graphs/include dir) (maybe) svn add 4.3/graphs/include svn commit -m "initial commit"

Alternative: svn mkdir svn+ssh:// cd 4.3 svn co svn+ssh:// . svn add nodes graphs graphs/include

(depends what directory level you want under version control, not a big deal - I wanted all of site-profiles potentially versioned)

The point is, you have to do a co to put the version control info in place. See also:

From there you just commit after changes. Do it as root, since you'll be editing files as root. root and all of our usernames are in an svn group that has write access to the rocks and config-files repo. You can certainly checkout and checkin as a normal user, but that's not really how we work with config files. Whoever you are when you checkout is who you will be when you checkin.

When you create a new file...

When you create a new file, you have to "svn add" it to your working copy. The easiest way to figure out which files you need to add is to run "svn status" - you get something like this:

[umopt1:nodes]# svn status
?      dcache-client-services.xml
A      cernsoft.xml
A      aglt2-kernel.xml
A      aglt2-condor.xml
A      interact-pack.xml
A      aglt2-network.xml
A      dellrepo.xml

A = scheduled for addition, it'll be transmitted next check in.

? = svn knows nothing about this file. Add it if you want to.

No output from svn status is good, it means all changes are committed to repository. Apparently it ignores backup~ files.

You can also add -v to status and see more.

Reviewing changes between revisions

svn diff is a local action, it compares the files in the working directory to the last checkout of the working directory.

Here's an example of using svn diff, specifying the revisions to diff between:

svn diff -r21:22

svn status -u will tell you the what has been updated in the repository vs. your working directory.

-bash-3.00# svn status -u site-profiles
Scientific Linux CERN SLC release 4.5 (Beryllium)'s password: 
       *       35   site-profiles/4.3/nodes/fss.xml
       *       35   site-profiles/4.3/nodes/dcache-pool.xml
       *       35   site-profiles/4.3/nodes/extend-ci.xml
       *       35   site-profiles/4.3/nodes/extend-oc.xml
M              35   site-profiles/4.3/nodes/aglt2-network.xml
       *            site-profiles/4.3/nodes/turn_off_dmraid.xml
       *       35   site-profiles/4.3/nodes
       *       35   site-profiles/4.3/graphs/default/my-appliance.xml
Status against revision:     45

To see information about revisions: svn list -v svn+ssh://ndt/repos/rocks/site-profiles/4.3

Also useful: svn log svn+ssh://ndt/repos/rocks/site-profiles/4.3 is also useful.

Both these commands work without a URL if typed in your svn working dir. (which is /home/install/site-profiles/4.3).
In that case, they list records up to the latest "svn update" you have done. I suppose the idea is that it chooses to only know as much as the working copy knows, though the operation always involves referencing the server as well. Without a URL, it only listed up to r5 until I did an svn update. The update changed no files, since the working copy was the same as the revision just checked in.

Convenience note

I set an environment var for the repository on For example:
svn log -v $REPO/rocks/site-profiles/4.3

Tom Testing

Here is the highest level you can list:

[root@msurox ~]# svn list svn+ssh://
Scientific Linux CERN SLC release 4.5 (Beryllium)'s password: 

This is because "rocks" is the repository. There are also other repositories. Not sure how you'd list them via svn, but they visible as directories in /repos.


svn copy

Copy a set of files (preserving history) from one area of the working copy to another. Change will be committed to repository at next commit. Note that svn doesn't expand wildcards and can't copy mulitple files in one command, so use xargs:

bash-3.00# ls -1 4.2.1/x86_64/RPMS/openafs-* | xargs -n 1 -I XXX svn copy XXX 4.3/x86_64/RPMS/
A         4.3/x86_64/RPMS/openafs-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-authlibs-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-authlibs-devel-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-client-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-compat-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-devel-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-docs-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-kernel-smp-1.4.4-2.6.20_20UL3smp_4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-kernel-source-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-kpasswd-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-krb5-1.4.4-4.x86_64.rpm
A         4.3/x86_64/RPMS/openafs-server-1.4.4-4.x86_64.rpm

svn add / del to replace a file

Want to replace an rpm in the contrib area. Need to do svn del on old file, svn add on new file, and then commit.

bash-3.00# pwd

bash-3.00# svn status -u
Status against revision:    171

bash-3.00# svn del dkms-2.0.10-1.noarch.rpm 
D         dkms-2.0.10-1.noarch.rpm

bash-3.00# cp ../../../../contrib-old/4.3/x86_64/RPMS/dkms-2.0.17-1.el4.noarch.rpm .

bash-3.00# svn add dkms-2.0.17-1.el4.noarch.rpm 
A  (bin)  dkms-2.0.17-1.el4.noarch.rpm

bash-3.00# svn commit -m "update dkms rpm" .
Deleting       RPMS/dkms-2.0.10-1.noarch.rpm
Adding  (bin)  RPMS/dkms-2.0.17-1.el4.noarch.rpm
Transmitting file data .
Committed revision 172.

A Merge

Merges apply previously recorded changes to a working copy. The diff between two specified revisions is applied to your working copy.

Have a working directory that is in-sync with a branch. There is a change to the trunk that I want to pickup --- the change is contained in one Revision, number 179.

So, want to do a merge to the working directory applying the difference between revision 179 and the previous. Look at svn merge --help, this is the third form. Afterwards, commit this change to the branch.

Note use svn merge --dry-run to test...

bash-3.00# svn merge -c 179 $SVN_ROCKS/trunk/site-profiles site-profiles
U    site-profiles/4.3/nodes/extend-compute.xml

bash-3.00# svn status site-profiles
M      site-profiles/4.3/nodes/extend-compute.xml

bash-3.00# svn commit -m "merge change from trunk into this branch" site-profiles
Sending        site-profiles/4.3/nodes/extend-compute.xml
Transmitting file data .
Committed revision 180.

Undoing commits

If have a commit that you want to undo or revert, the general way of doing so is to apply a merge which is the negative of the commit. This is done on a working copy (merges always happen to working copies...).

Here I have two revisions that I want to undo, 190 and r186. The syntax I'll use is svn merge -c -190. The minus sign merges the negative of the change r190 (i.e. undoes it). These two commands could also have been done in one with the command svn merge -r 190:179.

bash-3.00# svn merge -c -190 $SVN_ROCKS/trunk/site-profiles site-profiles-trunk/
U    site-profiles-trunk/4.3/nodes/extend-compute.xml
bash-3.00# svn merge -c -186 $SVN_ROCKS/trunk/site-profiles site-profiles-trunk/
G    site-profiles-trunk/4.3/nodes/extend-compute.xml

After verifying that the fix is good, commit it.

svn switch is your friend

svn switch takes an existing working copy and converts it to a different revision. The effect is that same (assuming you don't have files outside of revision control in the directory) as deleting your working area and then checking out the new revision. However, it is quicker if the revisions are near each other. (Given our computer and network performance, this isn't such a big time saver, still it is convenient.)

Operationally, using svn switch allows you to develop changes, apply them to a branch and then easily switch the working copy back to the trunk so that it is ready for ROCKS installs to be done.

bash-3.00# svn switch $SVN_ROCKS/branches/rockwell/site-profiles-node-info site-profiles
D    site-profiles/4.3/nodes/myricom_config.xml
A    site-profiles/4.3/nodes/myricom.xml
U    site-profiles/4.3/graphs/default/my-appliance.xml
Updated to revision 183.

bash-3.00# svn switch $SVN_ROCKS/trunk/site-profiles site-profiles
U    site-profiles/4.3/graphs/default/my-appliance.xml
D    site-profiles/4.3/nodes/myricom.xml
A    site-profiles/4.3/nodes/myricom_config.xml
Updated to revision 183.

Create a Repository

It is easy to create a repository for personal use on a local disk.

bash-3.2$ mkdir /SVN
bash-3.2$ svnadmin create /SVN/test

bash-3.2$ svn info file:///SVN/test
Path: test
URL: file:///SVN/test
Repository Root: file:///SVN/test
Repository UUID: 4acaf5c6-e5b6-44f1-a5ec-575a2174046b
Revision: 0
Node Kind: directory
Last Changed Author: rockwell
Last Changed Rev: 0
Last Changed Date: 2009-01-19 11:46:01 -0500 (Mon, 19 Jan 2009)

bash-3.2$ svn mkdir file:///SVN/test/tags -m "tags directory"
bash-3.2$ svn mkdir file:///SVN/test/branches -m "branches directory"
bash-3.2$ svn mkdir file:///SVN/test/trunk -m "trunk directory"

bash-3.2$ svn list file:///SVN/test

You can then use svn import to put files into the repo.

Setup an ssh key


Remote access to the server uses the "svn+ssh://" protocol, which tunnels to svnserve through ssh. Using ssh keys can make access more convenient but also allows additional control of how commits are done. Specifically a given ssh key can be mapped to a specific user in svn to perform the action as. For instance in the example of a ROCKS working area commit, there are these users involved:

Where Username Comment
local to the working dir root files in /home/install are owned by root
running svn command root the svn ci or svn co is run as root
account on ndt accessed via ssh root the ssh connection is made to the root account on ndt
"in" svnserve rockwell using the --tunnel-user option, a user other than root is specified

Note that in this scheme, the working dir is still owned by root, and since you are doing checkouts as root, newly checked out files will be owned by root.

Generate the key

Specify a passphrase to protect the private key.

[rockwell@cap svn-keys]$ ssh-keygen -t rsa -C "rockwell key for subversion on ndt" -f id_rsa-rockwell-svn-ndt
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in id_rsa-rockwell-svn-ndt.
Your public key has been saved in
The key fingerprint is:
4b:2a:e0:c9:12:d2:45:70:3f:b0:95:19:04:59:99:b3 rockwell key for subversion on ndt

[rockwell@cap svn-keys]$ ls -l
total 8
-rw-------  1 rockwell rockwell 1675 Apr 23 16:36 id_rsa-rockwell-svn-ndt
-rw-r--r--  1 rockwell rockwell  416 Apr 23 16:36

Setup on server

The string from the .pub file should be put into /root/authorized_keys, the command field is used to specify options to svnserve and to limit the function of the key so that it is only used to run svnserve.

command="/usr/bin/svnserve -t -r /repos/rocks --tunnel-user=rockwell",no-port-forwarding,
no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EA
Bef6KJjCLubGP5cgwWaT5zaGLgKkrV6XaYc8jw== rockwell key for subversion on ndt 

Note that this must be all on one line.

Note #2 The -r switch is going to modify the URL you use to access the repo. If another user comes along and isn't using that same method to access the repository, some commands on the local working dir won't work as expected for them...

Note last Setting LogLevel DEBUG in /etc/ssh/sshd_config will show the key fingerprint in system log when it is used.

Running svn client

Put the private key somewhere that it can be read from the root account (because you will run the svn client from the root account).

Now, when svn uses ssh to setup the tunnel, we want it to use our special (not the default in ~/.ssh/id_rsa private key). This is done by defining the SVN_SSH environment variable:

export SVN_SSH="ssh -i /root/.ssh/id_rsa-rockwel-svn-ndt"
-bash-3.00# svn list svn+ssh://    
Enter passphrase for key '/root/.ssh/id_rsa-rockwell-svn-ndt': 

Better way Now, we want to use ssh-agent so that we don't have to keep entering the passphrase during a sesssion. (There are more sophisticated ways to use ssh-agent, but this is effective.) Note that if you do this, you don't have to set the SVN_SSH variable as above.

-bash-3.00# ssh-agent bash

bash-3.00# ssh-add /root/.ssh/id_rsa-rockwell-svn-ndt 
Enter passphrase for /root/.ssh/id_rsa-rockwell-svn-ndt: 
Identity added: /root/.ssh/id_rsa-rockwell-svn-ndt (/root/.ssh/id_rsa-rockwell-svn-ndt)

bash-3.00# svn list svn+ssh://

-- TomRockwell - 03 Dec 2007
Topic revision: r31 - 22 Feb 2011, TomRockwell
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback