Complete migration from subversion to git

This is for those that want to throw subversion away completely, for some reason this is the easiest way to switch. First what you would do on the server:

# first clone the repository from subversion
# if you can use file:// it will be faster,
# otherwise use http://your-project-url.com/svn/MySuperProject
[server]$ git svn clone -s file:///home/pplux/.../svn/MySuperProject tmp
# clone to a bare new git repository (with no track of subversion)
[server]$ git clone --bare file://`pwd`/tmp MySuperProject
# remove the old git repo from subversion, no longer needed
[server]$ rm -rf tmp/
# update server info, for "dumb" servers this is needed
[server]$ cd MySuperProject/
[server]$ git --bare update-server-info


Now clients can simple clone your repository and start working:
# use this for normal-read-only, or maybe you could use ssh://
# if you plan to upload data.
[client] $ git clone http://your-server-url.com/git/MySuperProject


Mirroring the subversion repository and keep subversion

Here we want to keep the subversion repository like the main reference of the project, but let people (or ourselves) use git for development. The reason to mirror the subversion is just a matter of speed, it is much faster to clone an existing git repository than cloning from subversion each time.

Here we will need to do a bit more of work, but it’s a much smoother way to migrate from subversion to git. First what we need to do on the server:

# Create and initialize a bare git repository
[server]$ mkdir MySuperProject[server]$ cd MySuperProject/
[server]$ git --bare init
Initialized empty Git repository in /home/pplux/.../MySuperProject/


# set svn project to import
[server]$ git --bare svn init -s http://your-server-url.com/svn/MySuperProject


# fetch svn data (sloooow)
[server]$ git --bare svn fetch --all
A src/CMakeLists.txt
A CMakeLists.txt
W: +empty_dir: trunk/include
...


# auxiliary files to help "dumb" servers
[server]$ git --bare update-server-info


Now the client, here we will do much more work than before to setup both the origin from the git mirror and the subversion config to commit there future changes.

# Create and initialize our copy of the git repository
[client] $ mkdir MySuperProject
[client] $ cd MySuperProject/
[client] $ git init
Initialized empty Git repository in /Users/pplux/projects/MySuperProject/.git/


# setup the server as the initial origin of data
[client] $ git remote add origin http://your-server-url.com/git/MySuperProject


# also tell git to fecth data from the remote origin(that case svn)
[client] $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'


# fetch data from the git mirror(takes a bit)
[client] $ git fetch
got 2c68737541f19685f667f601a502447425d1fcfe
walk 2c68737541f19685f667f601a502447425d1fcfe
got d4916373650b9bb636c0284dd501e6c7bfa8e304
got 13af9568120f8e7771bd386d9b7dadf69f1181cb
...


# setup the original subversion as
[client] $ git svn -s init http://your-server-url.com/svn/MySuperProject


# rebuild data...
[client] $ git svn fetch
Rebuilding .git/svn/trunk/.rev_map.1a3bf6a2-ba3d-0410-9263-a3f888f14dcd ...
r1 = 126490373bfbc2a770d762398b67fffeef73bead
r2 = a2288725c8c68ef426b97cf2b28a9135a34734d3
r3 = 4158b92a5c68489bb6ff2b4f4567cf8f830d7282


# to start working create a master that will track "trunk"
[client] $ git checkout -b master -t trunk


Reasons for switching to git

The post ends here you can safely stop reading now, but if you ask me, there are some good reasons to switch to git:

• it’s faster, not only faster when doing actual SCM work, it allows you to develop faster, no need to wait while the commit is transmitted to the server, you can work offline wherever you are…
• it works well with subversion, you can use it even if the main project never moves from a subversion repository or you are the only one using git while everybody else is using subversion
• you don’t need to develop a full feature before a commit, you can work on your own doing commits often without worrying about anybody else.
• git is meant to work on branches, this is a different approach from the normal subversion use, with git you are supposed to work on branches, and it’s great! I like to develop different “features” on different branches, I can switch the branch, do several things at the same time… and so on.
• you have the whole history, not just the last commit.
• it’s secure, you don’t need several people to share the same repository, git “default” model works in a different way where each person has its own public git. But, everything in git is hashed, even branches, so you can easily check if your private git has the same things as the remote git (that’s difficult to achieve with subversion)
• it’s like vim vs notepad! I like git because is fun, it can do many many things, and it’s always good to have something new to play with.
• if CVS was for dinosaurs when you started using SVN, now SVN is for the Neanderthals… so start using git!
• You don’t have to be a ruby developer to use git! git is another SCM… not the cool tool just for cool ruby developers… come on.
• Because Linus Torvalds made it:
  
• … well, maybe Linus is not a good reason to use it… I don’t fancy calling people ugly and idiot, anyway git is great.

And big thanks to slack for pointing me out git, if he says something is good stuff… believe him

Other good links about what we’ve talked here:

http://www.gnome.org/~federico/news-2008-11.html#27
http://markmcb.com/tag/workflow/
http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-rebuildmeta
http://www.viget.com/extend/effectively-using-git-with-subversion/
http://techbase.kde.org/Development/Tutorials/Git#Interfacing_KDE.27s_SVN_repository_with_git-svn
http://live.gnome.org/GitForGnomeDevelopers
http://tsunanet.blogspot.com/2007/07/learning-git-svn-in-5min.html
http://blogs.gnome.org/johncarr/2008/06/21/git-mirrorgnomeorg/
http://markmcb.com/2008/09/17/migrating-a-subversion-svn-project-and-server-to-git/

Vamos a suponer que tenemos un repositorio con múltiples proyectos, cada uno de ellos con sus correspondientes ‘trunk’, ‘tags’, ‘branches’ como dice el libro de subversion. De algunos de ellos queremos hacer snapshots cuando se marque un nuevo tag, así que pondremos en el directorio hooks el siguiente script llamado post-commit ( se tiene que llamar así y además tiene que ser ejecutable, chmod +x):


#!/bin/bash
export PATH=/usr/bin:/bin
REPOS="$1"
REV="$2"
PREFIXES="/proyecto1 /proyecto2 /proyectoN"
OUTPUT_DIR=/path/donde/se/guardara/el/zip
for PREFIX in $PREFIXES; do
for tag in $(\
svn log -v -r $REV file://$REPOS | \\
awk '/^ *A */{if ($2~/'${PREFIX//\\//\\\\/}'\\/tags\\/[^\\/]*$/) print $2;}/^$/{exit}'\\
); do
file=${tag##*/}
svn -r $REV export file://$REPOS/$tag $file
zip -rm $OUTPUT_DIR/$file.zip $file
done
done

(bajar) versión completa

Si tu repositorio sólo tiene un proyecto, se puede simplificar un poco más:


#!/bin/bash
export PATH=/usr/bin:/bin
REPOS="$1"
REV="$2"
OUTPUT_DIR=/path/donde/se/guardara/el/zip
for tag in $(\
svn log -v -r $REV file://$REPOS | \\
awk '/^ *A */{if ($2~/\\/tags\\/[^\\/]*$/) print $2;}/^$/{exit}'\\
); do
file=${tag##*/}
svn -r $REV export file://$REPOS/$tag $file
zip -rm $OUTPUT_DIR/$file.zip $file
done

(bajar) versión simplificada

Por ejemplo, en un repositorio tengo una librería que utilizo para muchos de mis proyectos, llamada SLB, y en otro repositorio tengo mi proyecto killer-ap1. El proyecto de killer-ap1 utiliza activamente SLB, hasta el punto de que voy haciendo mejoras en SLB según veo que hacen falta en killer-ap1… por lo que suelo copiar SLB enterito dentro de killer-ap1 y compilarlo todo a la vez.

$ls proyectos/killer-ap1
src
include
SLB (mi copia particular)

El problema es que esta copia esta versionada una vez en el repositorio oficial y otras tantas en cada uno de los proyectos donde la uso, concretamente en killer-ap1. Además hay que acordarse de mantener actualizadas todas esas copias… por ello los de subversion idearon una solución mejor, los svn:externals.

La propiedad svn:externals nos permite enlazar en un repositorio con otros externos a este, de forma que cuando se haga un checkout del nuestro automáticamente también se bajará los otros. Ejemplo (de la página del svnbook):

$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
third-party/skins http://skins.red-bean.com/repositories/skinproj
third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker

Con esto estamos diciendo que el directorio calc tiene dentro tres directorios ‘thir-party/sounds’ ‘third-party/skins’ y ‘third-party/skins/toolkit’ que hacen referencia a repositorios externos(y en el último caso una revisión concreta la 21). También le estamos diciendo a subversion que cuando pase por calc se baje automáticamente los repositorios externos, y que los mantenga sincronizados.

Para mi caso de killer-ap1 y SLB la cosa ha sido así:

svn propset svn:externals “SLB http://svn.pplux.com/SLB/trunk” path/de/killer_ap1

Esta línea dice: “en el raiz de killer-ap1 vas a poner un directorio “SLB” que está sincronizado con el repositorio http://…”

Si en vez de uno tienes varios, los separamos con “\n”, el ejemplo del svnbook hubiera sido algo como:

svn propset svn:externals “third-party/sounds http://sounds.red-bean.com/repos\n third-party/skins http://skins.red-bean.com/repositories/skinproj\n third-party/skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker” calc

Un poco largo pero ilustra lo que se pretende, tener más de un external en un mismo directorio.

Y lo mejor de todo, que todas las copias siempre están sincronizadas, ya sean externals o no