Using Subversion

From WikiTissue

Jump to: navigation, search

Contents

[edit] Overview

The basic steps are

  1. Become a developer
  2. Create a subversion branch
  3. Check out branch and start working
  4. Merge with the sandbox

[edit] Become a Developer

One becomes a certified OpenTissue developer by making an email request to Jon Sporring. The request will be processed by the people that are currently QA responsible. These people are mainly interested in

  1. Who is making the request?
  2. Is the person able to comply with the style and programing guide lines of OpenTissue?
  3. Is the person sufficiently skillful in the black art of C++ template programming?

Usually this process is greatly speeded up if the person that makes the request has contributed with patches (or some other way) to the source code of OpenTissue. If one is accepted as an OpenTissue developer then one will receive an email with user account and password information for the image server.

  1. One should immediately log into the image server using SSH
  2. Change the password
  3. Setup public key authentication with SSH

Optional one can setup ssh keychaining.

[edit] SSH Keychaining

Another nice feature we are using with success is ssh-keychaining. The image server has ssh-keychain support which allow the ssh-protocol to tunnel your key-challenges through to other servers that has your public-key installed. This means that once you have identified yourself on one server using ssh-keypairs, you can ssh to all other servers that know you (and have ssh-keychain installed) without re-providing the key-phrase. This does require one to create a strong pass phrase, but only having to type this once is a great benefit.

We use it like this:

Create a ssh key-pair: 

  ssh-keygen -t rsa -C "[foobar@servername.com rsa-key-20060325]"
    (provide a good strong passphrase)
  scp .ssh/id_rsa.pub foobar@image.diku.dk:.ssh/servername_rsa_key
  ssh foobar@image.diku.dk (normal password here)
  cd .ssh
  cat servername_rsa_key >> authorized_keys2
  exit
  ssh foobar@image.diku.dk (should challenge for the passphrase)

Now you setup keychain on image: 

  emacs .bash_profile

 paste the following in at the bottom:

    # Support for keychain
    keychain id_rsa
    . ~/.keychain/$HOSTNAME-sh
    exit
    ssh foobar@image.dk (should challenge for passphrase and start keychain)
    exit
    ssh foobar@image.diku.dk (should use the existing keychain)

We use it extensively. On my (henrik) local linux-box I have installed a patch that allows me to login using my ssh-passphrase. On our windows-machines, we use putty's pageant (Putty Authentication Agent) to initialize the mechanism.

A much better explanation is located here: link keyc, link keyc2, link keyc3.

[edit] Creating a subversion branch

One creates a development branch to work in by making a server side copy of the sandbox, in the following we assume that ones login name is foobar.

Using the svn+ssh-approach is probably the only option right now. IIRQ the http-approach requires a separate way to control access.

When accessing through svn+ssh you use the file structure of the server. On image.diku.dk, the repository is located here: 

image.diku.dk/home/opentissue/svn/OpenTissue

To create a development branch, you therefore need to write: 

$ svn copy svn+ssh://foobar@image.diku.dk/home/opentissue/svn/OpenTissue/sanbox
svn+ssh://foobar@image.diku.dk/home/opentissue/svn/OpenTissue/development/foobar -m
"Creating a private development branch of OpenTissue/sandbox for foobar."

Using your image-username in the command ensures that you are not caught off your guards when trying this from a computer where your login-name is different.

The http-interface maps the above file structure (/home/opentissue/svn) to a virtual directory (/svn), which is why the paths looks different.

Next one can checkout the development branch 

svn co svn+ssh://foobar@image.diku.dk/home/opentissue/svn/OpenTissue/development/foobar OpenTissue_foobar

And start working. We strongly recommend that one merges the sandbox into the development branch on a regular basis.

[edit] Merge with the Sandbox

At some point one would like to merge new stuff or bug-fixes into the sandbox so everybody else can benefit from ones work. The work flow that we recommend is

  1. Merge all sandbox revision, since ones last merge into the development branch.
  2. Cross-compile the development branch on windows and linux, to make sure that everything is as standard compliant as possible.
  3. Merge development branch into sandbox.
  4. Update local working copy of sandbox and cross-compile on windows and linux to make sure that everything is working.

Ideally we try to make a clean-compile with max warning-levels on both VC++ and g++. We strongly encourage everybody else to comply with this ideal in as much as possible.

Merging from the sandbox and back into the sandbox does require some discipline. Please be sure to read about it in the Subversion link Book. Especially the notes about best Practices.


[edit] Naming Conventions

We have found it useful to use a change log entry looking like this: 

MERGE development/foobar rXXX:rYYY into sandbox

or 

MERGE sandbox rXXX:rYYY into development/foobar

Short info about what the merge is about/other info as in 

MERGE from development/kenny 2445:2446(HEAD) into sandbox
NOTE: Had to delete Trackball.h in my own repository first and commit that.

Otherwise, bulletin board are a great place to ask for help, or suggest stuff.

Retrieved from "http://www.opentissue.org/wikitissue/index.php/Using_Subversion"
Personal tools