Mirroring Transmission using Git

jch · Post by **jch** » Wed Nov 11, 2009 8:00 pm

After a few attempts, I have finally found the right setup for working on Transmission. Since it took me a few tries, I'll describe what I did.

1. The problem

The Transmission source code is managed using Subversion (SVN). Because of that, it is not easy to locally manage a set of local patches, keep track of which have been applied upstream, and refresh the remaining ones to apply cleanly to the new version.

The solution I finally chose was to keep a local mirror of Transmission using Git. I also tried using Quilt (which is too confusing for me) and Mercurial (which failed to convert the Transmission repository). Darcs, which would have been my preferred solution, is unable to speak SVN without the help of Tailor, which I find too complex. I didn't try Bazaar.

2. Install and set up Git

Install git, git-svn and (optionally) gitk. On Debian, do

Code: Select all

$ apt-get install git-core git-svn gitk

Then choose the name and e-mail that will be stored in your Git commits:

Code: Select all

$ git config --global user.name "Bill Gates"
$ git config --global user.email "bill@microsoft.com"

3. Convert the repository

You will need some 50MB of free disk space, plus whatever is needed for building Transmission (200MB is plenty).

Code: Select all

$ cd ~/stuff/transmission-work
$ git svn clone --stdlayout svn://svn.m0k/org/Transmission transmission

This should take the best part of an hour. After that, you will have a Git version of the Transmission under ~/stuff/transmission-work/transmission.

Since git-svn doesn't do SVN externals yet, you'll ned to manually import libevent:

Code: Select all

$ cd ~/stuff/transmission-work/transmission/third-party
$ git svn clone svn://svn.transmissionbt.com/libevent/branches/patches-1.4/libevent libevent

Note that we're not using --stdlayout here, but merely mirroring a single branch; this is okay, since we're not interested in hacking at libevent.

Finally, grab the file on

http://www.pps.jussieu.fr/~jch/software ... on.exclude

and put it in transmission/.git/info/exclude.

5. Working on the repository

Once you have all of that, you've got a functional Git repository that mirrors the Git repository, except that of course you cannot push and pull.

You can browse the repository using gitk --all; Jordan's trunk is the branch remotes/trunk. You can find out the list of locally committed patches on the current branch by doing

Code: Select all

$ git log remotes/trunk..

In order to pull any new commits from Jordan, and refresh your locally committed patches in the process, do

Code: Select all

$ git svn rebase

If you're worried that it might cause conflicts, and want to review Jordan's new stuff before merging, do

Code: Select all

$ git svn fetch
$ gitk --all              # review any new stuff
$ git rebase remotes/trunk
$

Branching works as usual (git checkout -b). However, it might be a good idea to base your local branches at Jordan's trunk rather than your local master, in which case you should do:

Code: Select all

$ git checkout remotes/trunk
$ git checkout -b the-name-of-my-branch

6. Conclusion

While centralised revision control systems might have their uses (which ones?), using a centralised system for a Free Software project places an undue burden on your contributors. If Jordan were using a distributed system, none of the above would be necessary -- it would be a simple darcs get, git clone, hg clone or bzr clone.

Juliusz