So now you have a working Git repo, fine. The only concern is how git-svn handles tags. Each SVN tag is converted into a branch, not a tag. For instance, tag 1.2 becomes git branch tag/1.2. git-svn might have a good reason for doing it but this is a bit disturbing to me, especially when you have dozens of tags polluting your ‘git branch’ output.
So I intended to convert all these branches into real tags, and delete them. Here is the command I came up with:

$ git-for-each-ref refs/remotes/origin/tags | cut -d / -f 5- |
while read ref
do
git tag -a "$ref" -m"say farewell to SVN" "refs/remotes/origin/tags/$ref"
git push origin ":refs/heads/tags/$ref"
git push origin tag "$ref"
done


Here is my use case: every new feature I code for ODE has a JIRA id. It’s a good practice to mention this identifier in your commit messages, so that people can quickly know which issue this commit refers to, and eventually consult the JIRA page to get all the information related to it.  Some tooling might even be built around this simple practice: for instance JIRA will index all the commits refering to a given issue.

Back to our case, so as I develop this new feature on my local Git branch, it happens that this JIRA id is rarely in my commit messages. Either because I forget, either because at the time of the commit I’m thinking to squash it later, etc. So when it comes to push these commits, I need to rebase my branch in interactive mode and manually edit each commit to prepend the JIRA id. Quite painful actually when you have a dozen of commits.

git-filter-branch makes that job in one single command:

$git-filter-branch --msg-filter "sed -e 's/.*/ODE-415: &/'" HEAD~8..

The argument is evaluated in the shell with the original commit message on standard input; its standard output is used as the new commit message. Nice..

No need to say that git-filter-branch should be use with care. The original refs, if different from the rewritten ones, will be stored in the namespace refs/original/.

Here is the problem. I couldn’t understand why the following XML document does not validate against the given schema.

	Something went wrong.

After some investigations and with some friends’ eyes, we figured out that the elementFormDefault attribute was the cause of our troubles. In the XML document the element is in the “ode” namespace but the XML schema sets the elementFormDefault attribute to unqualified. As Michael Kay put it, it “means that you want locally-declared elements like [reason] to be in no namespace.”

Even if “unqualified” is the default value, in most schemas, elements are qualified and I didn’t pay attention to that detail :/

So how does a valid document look like? One could be:

	Something went wrong.

There is no default namespace, so unqualified elements default to no namespace.

Another valid instance document of that schema may look like:

	Something went wrong.

The xmlns=”" declaration overrides the previous default namespace.

This article discusses in more details the raison d’être of qualified/unqualified elements.

I am still to be convinced that unqualified elements could be useful, but now I know that Axis2 generates schemas with unqualified elements and for now on I will make no assumptions on the value of that attribute!

ps: if you know why the XML names get down-cased by the Google syntax highlighter for Wordpress, drop me a line please.

It’s dated October 2nd, so forgive me if you have already read it, I’m catching up on my to-read backlog.

YouTube – Wassup 2008.

• Fuzed, a clustering system managing heterogeneous resources.
• Erlectricity, a Ruby program to receive and respond to Erlang messages
  sent over the Erlang binary protocol.

I was also amazed to hear that the Github completely bypasses the git executable to access git objects. Actually the Github guys have written a Ruby client to do that in a more efficient manner performance wise.

we have replaced a lot of the shell out calls in Ruby you do the shell out, we replaced most of those, possibly all of them by now with just pure Ruby, we go directly to the file system. We read the object data from the Git repository, we read that directly. And by doing that we have been able to get a multiplier of two speed up on the web pages throughout the site. Double the speed of the page load and that’s been awesome. So we are using that when you install Git.

InfoQ: Tom Preston-Werner on Powerset, GitHub, Ruby and Erlang.

Obama is RESTful » Idol Hands: Days in the Life of an Alpha Geek