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
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.
svn co svn+ssh://ndt.aglt2.org/repos/rocks/site-profiles/4.2.1
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://ndt.aglt2.org/repos/rocks/site-profiles . (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"
svn mkdir svn+ssh://ndt.aglt2.org/repos/rocks/site-profiles/4.3
svn co svn+ssh://ndt.aglt2.org/repos/rocks/site-profiles/4.3 .
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: http://subversion.tigris.org/faq.html#in-place-import
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
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
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)
* 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
* 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.
I set an environment var for the repository on umopt1.aglt2.org. For example:
svn log -v $REPO/rocks/site-profiles/4.3
Here is the highest level you can list:
[root@msurox ~]# svn list svn+ssh://ndt.aglt2.org/repos/rocks
Scientific Linux CERN SLC release 4.5 (Beryllium)
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.
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/
svn add / del to replace a file
Want to replace an rpm in the contrib area. Need to do
on old file,
on new file, and then commit.
bash-3.00# svn status -u
Status against revision: 171
bash-3.00# svn del 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" .
Adding (bin) RPMS/dkms-2.0.17-1.el4.noarch.rpm
Transmitting file data .
Committed revision 172.
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.
svn merge --dry-run
bash-3.00# svn merge -c 179 $SVN_ROCKS/trunk/site-profiles site-profiles
bash-3.00# svn status site-profiles
bash-3.00# svn commit -m "merge change from trunk into this branch" site-profiles
Transmitting file data .
Committed revision 180.
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/
bash-3.00# svn merge -c -186 $SVN_ROCKS/trunk/site-profiles site-profiles-trunk/
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
Updated to revision 183.
bash-3.00# svn switch $SVN_ROCKS/trunk/site-profiles site-profiles
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
Repository Root: file:///SVN/test
Repository UUID: 4acaf5c6-e5b6-44f1-a5ec-575a2174046b
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
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:
| local to the working dir
|| files in /home/install are owned by root
| running svn command
|| the svn ci or svn co is run as root
| account on ndt accessed via ssh
|| the ssh connection is made to the root account on ndt
| "in" svnserve
|| 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 id_rsa-rockwell-svn-ndt.pub.
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
-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 id_rsa-rockwell-svn-ndt.pub
Setup on server
The string from the .pub file should be put into
, 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
that this must be all on one line.
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...
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://ndt.aglt2.org/
Enter passphrase for key '/root/.ssh/id_rsa-rockwell-svn-ndt':
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://ndt.aglt2.org/
- 03 Dec 2007