Notes about open source software, computers, other stuff.

Tag: subversion

Getting the version of a remote SVN repository via SSH

A quick note to self: I wanted to find out what Subversion version was run on R-forge, which I access via SSH. This is how to do it:

$ ssh username@svn.r-forge.r-project.org svnserve --version
svnserve, version 1.6.17 (r1128011)
   compiled Nov 20 2011, 01:10:33

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository back-end (FS) modules are available:

* fs_base : Module for working with a Berkeley DB repository.
* fs_fs : Module for working with a plain file (FSFS) repository.

Cyrus SASL authentication is available.

Related Images:

The Raspberry Pi runs ProbABEL

One of the first things I tried on my Raspberry Pi was to compile ProbABEL and see if it runs. Since the Raspberry Pi has an ARM processor I wasn’t sure whether our code was portable to it. Apparently it is! Compiling ProbABEL (r.1027 from SVN) took 30 minutes (single threaded of course) compared to 34 seconds on my Desktop (4 threads on an Intel Core i3 processor), but hey, it worked :-). Surprisingly it also passed all the checks in make check.

Once I hook up some more storage to device I will try to run ProbABEL on some real data. It will be interesting to see how much time it takes to run a linear regression on e.g. chromosome 22 of HapMap3 imputated data for a few hundred samples…

Will the Raspberry Pi be the next platform for GWAS ;-)?

Related Images:

Subversion: merging updates in trunk to a branch

Yesterday I was working on ProbABEL, an open source package for running GWAS (genome-wide association studies). We use R-Forge and they provide us with a Subversion (SVN) server for revision control.

Some time ago we created a branch in which one of the co-developers is doing some major refactoring of the code. In the mean time I have been fixing bugs and adding new features to trunk. Now that the work in the refactoring branch comes to an end I thought it was high time to integrate the changes in trunk with the changes in the branch so that we can later promote the branch to trunk.

Since I had never done this before I decided to try the merge in the doc directory first, because I knew that in that directory nothing had changes since the branch was created, so all changes from trunk should be imported. At first I followed the SVN book instructions so I went into the doc dir in the branch and ran

$ svn merge ^/pkg/ProbABEL/doc

Unfortunately that didn’t work out. For some reasons conflicts appeared as wel as files that weren’t supposed to be there at all.

Thanks to Google and this blog post I found a solution. It boils down to explicitly telling SVN which revisions to use for the merge.

First I used

$ svn log | grep -C3 branch

to find out at which revision I created the branch:

------------------------------------------------------------------------
r864 | lckarssen | 2012-03-27 17:38:05 +0200 (Tue, 27 Mar 2012) | 1 line

Creating ProbABEL branch for code refactoring

Next I went to trunk and ran

$ svn update
At revision 987.

to find out at which revision trunk currently was. Back in the doc directory in the brach I ran

svn merge -r 864:987 ^/pkg/ProbABEL/doc

to merge al the changes since the branch was split off and it worked like a charm! All changes in trunk applied cleanly.

I then id the same for the other directories which also had changes in the branch. It turns out that when SVN find a conflict it is easier to postpone resolving the conflict because Emacs has a great SVN merge minor mode called SMerge! It highlights your changes vs. the incoming ones and allows you to select a resolution and move to the next conflict with a few easy keystrokes. After all conflicts have been resolved Emacs automtically removes the intermediate files SVN created and you are ready to commit.

Related Images:

© 2024 Lennart's weblog

Theme by Anders NorĂ©nUp ↑