by Ron Bieber on Tuesday, March 3, 2009
We’re looking to implement a pilot of Git to familiarize the team with the tool and introduce them to the more flexible workflow that Git supports over SVN. Because we support concurrent lines of development, we would like to forego the usual way of using git with SVN (each developer clones a branch of the repository and commits there) and try to implement a pure git experience using an intermediate “project repository”. The idea behind this repository is as follows:
- We clone the main subversion repository using git svn
- An empty project repository is created on the server and the Subversion clone is pushed to this repository (its an additional remote).
- The development team clones the project repository and proceeds to do development in their own clones. Periodic pushes to and pulls from the project repository keeps each developers master branch up to date, from which they can rebase their local branches.
- Periodically (probably daily), the originating SVN clone is ‘svn rebased’ and the new changes pushed to the project repository. These changes will be pulled by the developers on the next pull from the project repository.
In picture form, the workflow looks something like this:
Nevermind – StackOverflow ruined it for me.
by Ron Bieber on Friday, June 29, 2007
I decided to upgrade my home Subversion repository to version 1.4.3 as soon as it was released. Since then, my ViewVC application has ceased to work, getting a Python exception every time I try to execute it. Creating a small Python program that just imports the library (from svn import fs) gave me the following error:
ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_load_error_strings
Thinking it was an SSL library problem, I upgraded SSL – a few times. I kept mucking with the options, rebuilding Subversion, only to get everything installed and get that same error:
ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_load_error_strings
Over, and over and over again I repeated the process and got the same result. The absolute definition of insanity. This has been going on for a couple of months and I’ve been trying to address it in my spare time, as I’ve been pretty busy lately during the week and gone to the Relaxation Unit the last few weekends.
I googled my ass off to find the error, but to no avail. Finally today I ran across this thread that explained the problem. After going through my distribution directory for 1.4.4 (which I upgraded at the beginning of the month only to receive the same error) I realized that I hadn’t pulled down the Subversion dependencies tarball and rebuilt neon. So, basically I was using an old version of the neon libraries.
I finally settled on the configure statement listed here, after downloading and untarring the deps file:
./configure --with-ssl --with-apxs=/usr/local/apache2/bin/apxs \
--with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2 \
--enable-shared --with-libs=/usr/local/ssl
This uses the already installed apr libraries that I build with my Apache server, and ensures that the neon shared libraries are built. A quick configure/make/make install/make swig-py/make install-swig-py sequence later and my Python libraries were working fine.
I made it a point this time to document this on the Labs internal wiki, but thought I should throw this out here in public so that others can find it. Hope it helps save the weeks of frustration that I have been suffering for someone out there.
Happy building …
by Ron Bieber on Thursday, April 5, 2007
