HowTos / SvnSetup

Setting up a Subversion Repository on the Cluster

Next: Importing projects to SVN


The first thing to do is decide on a layout. Subversion assumes that you will want to do thing like create branches (have 2 or more different versions of your software that have much of the same code, but diverge at some point) and releases (called tags in svn, these are snapshots of the software at particular points that are easily referenced, usually when relatively bug-free as "official releases"). It is easiest to have your directories organized to reflect this organization. The following examples are from the Subversion book, a book I recommend looking at. I also have a hard copy of it, if you prefer. If you have 3 projects, calc, calendar, and spreadsheet, your layout may look like this:

 /
   calc/
      trunk/
      tags/
      branches/
   calendar/
      trunk/
      tags/
      branches/
   spreadsheet/
      trunk/
      tags/
      branches/
   …

Note that it doesn't matter where in your repository each project root is. If you have only one project per repository, the logical place to put each project root is at the root of that project's respective repository. If you have multiple projects, you might want to arrange them in groups inside the repository, perhaps putting projects with similar goals or shared code in the same subdirectory, or maybe just grouping them alphabetically. Such an arrangement might look like:

 /
   utils/
      calc/
         trunk/
         tags/
         branches/
      calendar/
         trunk/
         tags/
         branches/
      …
   office/
      spreadsheet/
         trunk/
         tags/
         branches/
      …

Lay out your repository in whatever way you see fit. Subversion does not expect or enforce a particular layout—in its eyes, a directory is a directory is a directory. Ultimately, you should choose the repository arrangement that meets the needs of the people who work on the projects that live there. Note that your local copy does not have to look like the repository. For example, if you are only working on the calendar project above, and you are troubleshooting, and not making new features, you may just want to check out the trunk of the calendar and put it in a calendar directory. Later on, if you decide to put in a new feature, you could create branch and put it in a new directory. These can be updated separately, as you can sync with whichever directory you want in the repository tree.

More information on layouts is available in the subversion book, and layouts are not difficult to change using svn commands after they are created.

Once you have a layout decided, it is time to create your svn directory. This is a directory where all of the databases and backend stuff for svn will go, so you will never actually edit anything directly in this directory. I just create a directory called svn in my root directory, so it is simple for accessing. So, the way this works is that you have a layout created like above within the repository in your linux home directory. If you decide to do work on the linux machine then you "checkout" a copy (the working copy) of the repository to another directory and use this to make changes to the code. You could additionally, or instead, create a working copy on a different machine. Using subversion, you can update your working directories (on any machine) to the repository so it includes any recent changes, or update the repository to reflect any changes you have made in your current working directory. You can "checkout" the entire repository, or just a portion of it.

If this is a project you will be working on with others in the lab, you should just add to the repository already existing in /lab/subversion. This will make it much simpler for others to access your repository.

You can look at the repository there:

maria@miles:~$ svn list svn+ssh://miles.shadlen.org/lab/subversion
maria@miles.shadlen.org's password: 
ShadlenDotsX/
branches/
save_dot_pos/
tags/
trunk/

In general, you should create a new top level directory for a new project that will be released as a separate entity, and create trunk, branches, and tags underneath it. In the lab directory currently, there are two top level directories like this, ShadlenDotsX (the version of shadlendots for OS X, and save_dot_pos which is a bunch of files to be put on rig machines in order to save the dot positions. Under each of these directories are trunk, branches, and tags directories. Because of the way things were moved from the old cvs repository, there are a few directories in the top level trunk:

FIRA/
ShadlenDots8/
Utilities/
rex/

Now you should be able to see how things are setup in the repository, and you can look at the next section to find out how to check out a particular directory or how to add to the repository.

If this is a solo project, and you want to create a repository in your home directory instead, use the following command (you could choose a different name for your repository, but svn seems a good choice: remember you won't actually be editing in this directory):

svnadmin create /home/test/svn

Now it is time to fill your repository. If you do not already have projects started that you want to import to svn, you should create a simple directory structure, as shown above, for your new project, and just import that.

Next: Importing projects to SVN

Svn - Introduction to Subversion
SvnImport - Importing projects into a Subversion Repository
SvnRemote - Accessing your Subversion Repository Remotely
SvnRemote-Draft - Accessing your Subversion Repository Remotely
SvnSetup - Setting up Your Subversion Repository
SvnWork - Basic Subversion Work Cycle