Category: hacks

Svn in the git era without driving insane


If you, like me, are used to the beauty of git and create a branch for any single feature you would like to add to the master branch you are upset if you end up in a company that only uses svn as revision control system and they are not willing to make a switch anytime soon.

Some people, even dev managers, sometimes can’t understand how much more productive a good tool make employees. If you are used to merge the code or rebase with git you will find the merging tools of svn kinda obsolete. The fact that if somebody is doing a merge nobody else can commit to svn or everything may break is simply an insane idea for me.

If you are stuck in this kind of environment, you have a savior: it’s called git svn. I’ve been using it from more than one year now and I feel it great. The main concept is simple: git svn imports svn repositories into git ones. After this you can use them as normal git repositories. You can, for example, commit, rebase, rebase interactively, merge and then commit back to svn in the right branch. Git will figure out which is the right branch, but you can change it of course. To start with git svn just clone a svn repository with:

git svn clone -s svn://

The -s will tell git to expect a standard format of svn, the one with a directory for trunk, branches and tags. If you are so unlucky to work with a not standard repo, you can use the -T -t and -b to specify the layout for trunktags and branches. This command will start fetching from revision #1 and will apply all the subsequent revisions. If you have a big repository (i’ve one with 50000 commits) you clearly don’t want to do that unless you don’t want your pc to spend days in fetching all reviews. You can tell git to only fetch the latest N revisions with :

git svn clone -s -rN:HEAD svn://my_cool_server/my_cool_project/

where N is a number.

After cloning, your new repo you can access your svn branches over remotes/BRANCH. This means that you can easily create a local branch that will track a svn branch with:

git checkout -t remotes/BRANCH

You can now do all commits, merges, rebase, interactive rebase you want, and even look at the svn patches and log with git log.

And finally, when you want to commit on the remoted tracked branch you simply do:

git svn dcommit

Sweet, isn’t it ?

How to make usb disks readable by all users on Raspbmc


In a past article I wrote about a comparison of Openelec, Raspbmc and Xbian. That article hit a record in terms of number of readings and comments on this blog. I spoke about some modification I had to do to Raspbmc to make it usable for my needs but I din’t show them. In this article I’m going to fill this gap.

In order to make the usb drives be mounted with writing permissions to all the user of the system I’ve modified the /etc/udisk-glue.conf as following (in bold are the part that I’ve added:

filter disks {
 optical = false
 partition_table = false
 usage = filesystem

match disks {
 automount = true
 automount_options = { sync, noatime, <strong>"dmask=0", "fmask=0"</strong>}
 post_insertion_command = "udisks --set-spindown %device_file --spindown-timeout 1800 --mount %device_file --mount-options sync,noatime,<strong>dmask=0,fmask=0</strong>"

And I had to let udisk-glue run as root as following:

# udisks-glue

description "udisks-glue for udisks"

start on started dbus
stop on (runlevel [06] or stopped dbus)

expect fork

#exec su - pi -c "udisks-glue"
exec udisks-glue

(I’ve changed udisk-glue such that It’s run by root)

Since there are a lot of folks out there that are using this distro I think it’s is worth sharing this knowledge. If some dev is reading this, please consider to propagate this changes (or do equivalent ones) to the distro in order to increase flexibility.

%d bloggers like this: