Biowiki Subversion

From Biowiki
Jump to: navigation, search

How to use the biowiki subversion repository

  1. List files in the repository
  1. Create a dummy project on your local machine
    • mkdir my-local-project
    • touch my-local-project/my-file
  1. Import your dummy project into the remote repository
  1. List projects in the remote repository
  1. Check out a copy of your project
  1. Add a new file to your project
    • cd my-project
    • touch my-new-file
    • svn add my-new-file
    • svn commit (or svn ci)
    • cd ..
  1. Remove a file from your project
    • cd my-project
    • svn rm my-file
    • svn ci
    • cd ..
  1. Update your copy of the project (after someone else has made changes)
    • svn update (or svn up)
  1. Delete your dummy project. NB you can use the -m option to pre-empt the entering of log messages in the text editor
    • svn rm -m "taking out the trash..." my-project

Note: if your local username doesn't match your username on, you can prefix the domain name with your username followed by the @ sign, e.g. svn list svn+ssh://

-- Ian Holmes - 11 Nov 2005

Problems with Subversion database corruption

Sometimes the Subversion database becomes corrupt (or something to that effect) and needs to be repaired with:

$ svnadmin recover /svn $ chmod -R g+w !$

where /svn is the Subversion database directory on the host machine. Ian Holmes found the following solutions to remedy the problem:

  I found some stuff on this

  Here is the checklist from the last page

  (1) All of your SSH users need to be able to read and write to the
  repository.  Put all the SSH users into a single group. Make the
  repository wholly owned by that group, and set the group permissions to

  (2) Your users need to use a sane umask when accessing the repository.
  Make sure that svnserve (/usr/local/bin/svnserve, or wherever it lives in
  $PATH) is actually a wrapper script which sets umask 002 and executes the
  real svnserve binary. Take similar measures when using svnlook and
  svnadmin. Either run them with a sane umask, or wrap them as described

  (3) When [[Berkeley DB]] creates new logfiles, they need to be owned by the
  group as well, so make sure you run chmod g+s on the repository's db

  I've already done (1) so I guess we need to do (2) and (3)

There haven't been any problems in the weeks since we implemented the above 3 remedies.

-- Andrew Uzilov - 07 Feb 2006

Misc notes

Some links on the Subversion code conflict resolution mechanism that Ian Holmes sent me:



-- Andrew Uzilov - 07 Feb 2006