Posts Tagged ‘svn’

Bugs and SVN

Sunday, May 4th, 2008

I had my first bug assigned to me today, and yes its the obvious one: http://bugzilla.gnome.org/show_bug.cgi?id=48004

I’ve also had my SVN account approved and am just waiting for the accounts team to do the final check and set it up, although I probably won’t use it all that much as I’ll be doing my development in my local git repository as i described earlier.

Git svn and Gnome

Friday, April 25th, 2008

Since my work is going to span across many modules and that each of these modules are in it’s own svn repository, I have decided to use git-svn as a source control tool. I will be publishing my git repository at git.jsharpe.net once I’ve got ssh access enabled on my server.

Using git to access svn repository
Some of you may be interested in how to use git to access a svn repository. (A more comprehensive guide is available here) This is how I used it to clone the gnome repositories:

First run:
git svn clone http://svn.gnome.org/svn/jhbuild -T trunk -t tags -b branches
This tells git to clone the jhbuild svn repository with trunk directory named trunk, tags directory tags and branches directory branches. (A pretty standard repository layout however if the repository is laid out in a non-standard fashion there are ways of making git svn play nice here too - ask if you’d like to know).
This will churn away for a long time checking out every single revision from revision 1 to obtain the complete history( the -r flag can be used to reduce the number of revisions that are checked out to a smaller number).
Once this is completed we will then have all the branches and tags from the svn repository available as remote branches.

Space Savings using git over svn
I’m still amazed at how well git compresses repositories. After cloning the nautilus repository the .git directory was 2.0G. Running the command:

git gc –prune –aggressive

compresses this down to 381M.

Working with a git svn repository
Keeping up to date is simple. You simply run the command
git svn fetch
from within your working copy. This will download all updates on all the branches and tags from svn that happened since you last updated. (Incidently if during the initial clone step your connection dies or you need to stop it then to resume the clone you just have to run the above command to resume downloading the history).

Day to day development then should occur on a branch which is then rebased against the master when svn updates are pulled down. Changes can then be pushed back to svn using git svn dcommit.