Home page Models Systems Tools IT staff References
Installing Subversion Using Subversion
Subversion is a version control system. It is used to manage the files for a software project as that project evolves. There are two sides to subversion - server and client. The subversion server runs on the computer where the subversion archive resides. A subversion client runs on a user's computer. The user uses the client to make requests carried out by the server - to check out the source code for a project, to commit to the server changes a user has made to the source code, to receive updates to the source code of changes other users have made, etc.
This is the Subversion web site.
The subversion server is managed by the Kirshner lab IT staff. It is currently on innoculant.
The svn client program available from the subversion project at SourceForge is a command line client. There are also GUI clients available for some platforms, such as the standalone Tortoise SVN for Windows, the Subclipse plug-in for Eclipse and the built-in svn support in Qt Creator and Xcode.The command line client of subversion is not required for a platform where a GUI client has been installed. It is usually installed anyway. It is documented and stable, so it can be useful for diagnosing problems with another svn client. Some people prefer the svn command line client. Once familiar with it, it can be faster and simpler to use.
Subversion is not installed by default on any system, but it is often already installed since it is used for every software project managed by the labs. So check to see if an svn client is already installed. To check for the command line client type "svn --version" from a terminal window command line. If you get a response like "svn, version 1.6.5 (r38866)" then it is installed. Otherwise you get a message like "No command 'svn' found" either svn is not installed or the location of the svn client program is not in your execution path".
sudo apt-get updatesudo apt-get -y install subversionOS/X 10.5 or greater is required. There isn't a version of subversion available for OS/X versions prior to 10.5 (at least that are easily found or obtained).
Subversion is installed as part of the Xcode installation. This is the best way to have subversion, since a current version of Xcode is essential to doing development on a Mac.
If subversion is not installed, and getting it as part of Xcode is not an option, you can use the following installation procedure.
From http://www.open.collab.net/downloads/community That page has a pull down menu labeled "Choose Your Platform". Select the "Community" menu item and click the Go button. Downloaded Universal Subversion 1.6.xx Binaries for Snow Leopard (Mac OS X 10.6), a file with a name like Subversion-1.6.17-10.5.x.dmg This requires registering with CollabNet, which is free (if annoying).
Double click the downloaded file to open it (mount it). There should be a single file in the window that opens (with a file name something like Subversion-1.6.12). Double click file to start the installer.
Is it in mingw? Only use Tortoise SVN?
There is a free online book for Subversion. Chapter 1 gives an overview of version control in general and subversion's approach to version control in particular. Chapter 2 is a tutorial on basic use of subversion using the command line client. This is sufficient for the purposes of our projects.
Online help for svn's command line program is available with svn help.
To get help on a particular svn command use svn help command-name,
for example svn help co for help on the checkout command.
Here are some examples of basic svn use using the command line svn client. These use the command abbreviations instead of the full command names: co for checkout, up for update, ci for commit, etc.
To perform similar tasks using a GUI svn client, see the description of that client, available from the tools page. The examples are for a model called GR-ABM-ODE-3D in the source archive. Use the same commands, but with the svn directory location for that model. This will be specified in the page for a model, accessible from the models page.
Depending on the local system configuration, when you run an svn command svn may ask for a password. The prompt will be something like:
Authentication realm: <svn://innoculant.micro.med.umich.edu:3690%gt; Dev
Password for 'pwolberg':
Enter your password for our local svn server. This is usually the same as the ID mentioned in the prompt, or some variation of that. You should have received an e-mail message with your svn ID and password. If you don't remember it and can't find the e-mail with it, contact the Kirschner Lab system administrator.
To get a complete fresh copy of the source code for a model, use the "svn co" command.
svn co svn://innoculant.micro.med.umich.edu/dev/model-directory-path
For example, to check out a fresh copy of the 3D lung model:
svn co svn://innoculant.micro.med.umich.edu/dev/GR-ABM-ODE-3D
This will create a sub-directory of the current directory called GR-ABM-ODE-3D.
To check out an older revision of a model, use the "svn co" command as before, but also specify an explicit destination directory and use the "-r" option to specify a specific revision to check out. For example to checking out revision 100 of the 3D lung model:
svn co svn://innoculant.micro.med.umich.edu/dev/GR-ABM-ODE-3D GR-ABM-ODE-3D-100 -r 100
This will create a sub-directoty called GR-ABM-ODE-3D-100 of the current directory. You don't have to specify the directory to contain the checked out source, but otherwise svn may try to check it out into an existing directory, so its best to specify an explicit target directory. It is also a good ides to put the version number in the target directory name so you can more easily keep track of which revision this directory is for.
If you already have a copy of a model's source code checked out and want to update it with the latest version (if others have made changes), then use the following command. No svn URL or archive path is specified, svn knows where the archive is and what archive path to use because it remembers what was used on the "svn co".
svn up
When you do an update the files that are retrieved from the archive are displayed along with a 1 letter code indicating what was done with that file. Some of the codes are:
The changes from the archive were on different lines than the changes you made, so there was no conflict as far as svn is concerned. It is a good idea to examine the changes using a difference tool.
To commit changes you've made to the svn archive:
svn ci -m "Log message with a general description of your changes"
You might get a message something like Transaction is out of date.
This means that someone else has committed changes to the archive after you last
did a checkout (svn co command) or an update (svn up command).
You need to do an svn up command and resolve any
conflicts before you can do a commit.
You can configure svn to always prompt for log messages from within a text editor.
This makes it easier to enter log messages, especially long ones, since you can edit
them more easily than on a single command line. It also has the advantage of making
it more difficult to forget to enter a commit log message since svn will always
prompt for one when configured to use an editor for log messages.
Add the following line to the end of your shell's configuration file, typically
~/.bashrc. Use any text editor to change it or create it. If you create it make sure
it is in your home directory, otherwise it won't have any effect. Also, it won't have
any effect in any terminal window already open. To have it take effect in an open terminal
window, use source ~/.bashrc in the open terminal window, which runs the
updated .bashrc file.
export EDITOR=editor-name svn commit
For example:
export EDITOR=vi svn commit
Or:
export EDITOR=nano svn commit
When you do an svn commit, svn will bring up the editor with text like the following,
showing the status of files (as would be displayed by an svn st command)
below the line to be ignored.
--This line, and those below, will be ignored-- M simulation/grmain.cpp
Enter your log message above the line to be ignored. It can be as long as you like. If you use a method for saving the entered text before (or as part of) exiting the editor then svn will perform the commit (ex. "ESC :wq" in vi or Ctrl-O and then Ctrl-X in nano). If you exit without entering any text or by exiting without saving the entered text then svn displays the following prompt:
Log message unchanged or not specified (a)bort, (c)ontinue, (e)dit:
If you enter "a" svn aborts the commit. "c" will cause svn to perform the commit without a log message (generally a bad idea) and "e" will return you to the editor to enter a log message.
Conflicts occur when someone else has also made changes to a file and committed them to the archive
after you did a checkout (svn co command) or an update (svn up command),
and you have made changes to the same file and some of your changes were to the same lines as the
changes already committed. In this case if you do an update svn cannot automatically merge your
changes with the changes from the archive.
There are two approaches. First, svn will prompt you for what to do for each file that has conflicts - keep the changes from the archive and discard your (what svn calls "their" changes), keep your changes and discard those from the archive (what svn calls "mine" changes) or postpone handling the conflict.
Keeping the changes from the archive and discarding yours is sometimes useful. If you were just experimenting with some changes and don't need to keep them. If that is the case then "keeping theirs" is the simplest choice.
If you know that both sets of changes are needed or you are not sure then choose to postpone handling the conflict. svn will create 3 new versions of the file. One with just your changes, with ".mine" appended to the file name (ex. main.cpp.mine), one with the file as it was when you retrieved it from the archive before you made your changes, with ".rOldRevisionNumber" appended to the file name (ex. main.cpp.r100), and and one with the changes from the archive, with ".rNewRevisionNumber" appended to the file name (ex. main.cpp.r101). There will also be a file with the original file name (ex. main.cpp) which will have both sets of changes delimited by special lines added by svn, which will look something like this:
<<<<<<< .mine
Lines with your changes
=======
Lines with changes from the archive
>>>>>>> .r101
These added lines, one set for each conflict in the file, mean that builds will no longer work because the source file will not compile. Edit the file so that each conflict has the changes you think it should have - just your changes, just the changes from the archive, or much more likely some combination of the your changes and the changes from the archive. Be sure to delete the "<<<<<<<" and "=======" lines as part of this editing process, otherwise the file won't compile.
Once you have edited the file to resolve all the conflicts, use this command:
svn resolve file-name
For example:
svn resolve main.cpp
This telles svn that you have edited the file to resolve all the conclicts. svn will deleted the other versions of the file, (the ".mine", ".rOldRevisionNumber", ".rNewRevisionNumber" versions) and will no longer consider the file in conflict. Once this is done for each file in conflict you will be able to do an svn update.
If you enter an svn command and receive the message svn: '.' is not a working copy it means you entered
an svn command that only works in an svn working directory (a directory where files where placed from an svn checkout
(svn co command) but the current directory is not an svn working directory. For example, suppose you do a
check out from svn while in directory "immunology", ex. svn co svn://innoculant.micro.med.umich.edu/dev/GR-ABM-ODE-3D.
Then "immunology/GR-ABM-ODE-3D" is an svn working directory, but you "immunology" is still the current directory. The
command svn info will produce the error message "svn: '.' is not a working copy". If you do
cd GR-ABM-ODE-3D then the svn info will work (which displays version information about that
svn working directory).