pygit-svn-mirror 0.1 released

I have been looking for easy and quick solution to mirror Subversion repositories in Git at GitHub. With bit of reading and testing, I came up with some quite usable workflow. But, most likely due to my lack of Git fu, I wasn’t happy with it. Especially, could not find how to update Git mirrors from various locations and computers, also to allow others to do that.

Lately, I have found a tool written in Ruby by Eloy Durán. It is git-svn-mirrora command-line tool that automates the task of creating a Git mirror for a SVN repository, and keeping it up-to-date. I installed Eloy’s tool from Ruby gems and played with it for a while. I really liked it.

I skimmed the Ruby code of git-svn-mirror and found out it makes use of bare repositories in Git. A Git bare repository stores just the contents of the .git directory, without any files checked out around it. Long story short, this script does almost exactly what I need and if there is something it does not do, then I can add it.

I have never written a single line of code in Ruby and I don’t feel like I need to learn it now. So, I decided to port git-svn-mirror to Python. I have just pushed pygit-svn-mirror 0.1 based on git-svn-mirror 0.1 to the repository at GitHub. I have tried to follow command line interface and overall code structure of the original version in Ruby. I have also preserved the original license and Eloy’s copyright.

There is README.md file included with detailed guide on how to use the pygit-svn-mirror. Basically, there are two commands: init and update. For each command, --help option will display required and supported arguments.

For example, creating mirror of Subversion repository of PROJ.4 project at GitHub involves the following commands:

mkdir /path/to/proj4/mirror
cd /path/to/proj4/mirror
git-svn-mirror.py init \
  --from=https://svn.osgeo.org/metacrs/proj/ \
  --to=git@github.com:<USRNAME>/proj.4.git

and to update the mirror from its workbench directory:

cd /path/to/proj4/mirror
git-svn-mirror.py update

or from any folder but with workbench location pointed explicitly:

git-svn-mirror.py update -w /path/to/proj4/mirror

Feedback, bug reports and patches highly appreciated.

Finally, big thanks to Eloy Durán for the original git-svn-mirror written in Ruby.

Preparing for Subversion to Git migration

GEOS is slowly moving to Git, so I decided to clear the Subversion specific settings, namely the svn:keywords. The procedure is quick and based on the commands I used to perform bulk svn:keywords property update.

First, svn:keywords property is removed:

find . -path '*/.svn' -prune -o -type f -print  | xargs svn propdel -q svn:keywords

Next, line consisting of $Id$ keyword is stripped from every plain text file using a tiny script coded in Python:


#! /usr/bin/env python
import fileinput
import re
import sys

def strip_line(filename, rx):
    sys.stderr.write(filename + '\n')
    for line in fileinput.input(filename, inplace=1):
        m = re.match(rx, line)
        if m is None:
            sys.stdout.write(line)
        else:
            sys.stderr.write(line)

if len(sys.argv) < 2:
    sys.exit("Missing filename")

pattern = '^.*\$Id.*$'
rx = re.compile(pattern, re.DOTALL)
strip_line(sys.argv[1], rx)

The script is executed for every file, excluding the working copy admin area in .svn:

for f in `find . -path '*/.svn' -prune -o -type f -print`; do ~/bin/strip_line_regex.py $f; done;

Voila!

Update: Torvalds answers Does GIT has vc keywords like CVS/Subversion?

Using Git with GDAL repository

I have mirrored Subversion trunk of GDAL repository on Gitorious – a free hosting for collaborating on distributed open source projects. It is available as svn-trunk repository of gdal project.

The main motivation is that it simplifies development of experiments in case one needs version control or complete disconnection from SVN trunk for some period. Thanks to git-svn, it is possible to push changes back to the trunk.

I outlined the process of maintaining GDAL trunk using Git in the Wiki article Using Git To Maintain GDAL Workflow.

The synchronization is not a time consuming process at all but even that I hope to make it automatic process in near future. First, I have to ship my little personal server to a remote data centre and I’m hoping to do it next week. Lucky bastard going to bask in the warm sun of Portugal :-)

Tortoise*

After diversity of operating systems, diversity of versions of diversity of compilers and forks of forks of favourite…forks of projects, contributors to the world of Free and Open Source Software got Yet Another Nail in Their Asses (YANTA with tm by myself). It is the variety of revision control systems and their clients developers need to install to be able to do their job. In the past the choice was clear CVS and later Subversion.

Today, DVCS is posh. So, an average developer who wants to contribute his cheap liberty to number of Open Source projects, will likely have to juggle clients to three or four kinds of the posh revision control systems.

For Windows systems, we have the whole population of turtles on the land: TortoiseSVN, TortoiseGit, TortoiseBZR and TortoiseHg (hopefully, none of them are listed as endangered species). The stack of these turtles causes the context menu large enough to make it hard to use on small screens. Combinations of authorization systems, configuration files and mess with Putty and MinGW/MSYS dependencies…make participation in this whole libertinism ridiculously complex.

I’m really surprised no one of the Tortoises hackers have come to the conclusion that it would be not a bad idea to merge their efforts and develop single client capable to work access repositories of all the four types of systems. Of course, with single installer and one submenu in the Windows Explorer’s context menu. Ah, and please don’t forget about including command line clients too :-)