Johns Blog

A few days ago, I saw a blog post highlighting how difficult it can be to sync a phone on the free desktop. For a battle hardened command line user, the steps aren’t that troubling (although that example looks easy compared to some of the setups i’ve seen). Regardless, I certainly wouldn’t want to put my parents through this experience.

In contrast, after a recent mishap with my phone, restoring its address book from Evolution was trivial with the copy of Conduit SVN I had kicking around.

I started Conduit and plugged in my phone. It appeared on the left hand side of the screen, so I dragged it and the Evolution endpoints to the canvas, and I did a sync. My address book is back.

There is more UI love to go of course. SynCE automagicness is getting there, but we can make it even better. Plus, we love HAL, and the next step is to respond to new devices and say “Hey, I know how to deal with that thingy you just plugged in” and offer to sync to some sensible defaults (Evolution for PIM stuff, Tomboy for Notes, F-Spot for Photos, Banshee/Rhythmbox for Music). And of course, the next time I plug it in.. Just sync it. Never make me press the sync button again.

The blinding future is to use PackageKit to download extra support packages like SynCE and libgpod as needed, when you plug in the device.

I still have Google Beer tokens (8 or so) lying around. And to my wrist are fastened 2 Electronica festival istanbul 2008 tags. Win.

Now to pack for home…

I cannot remember after a certain hour. If you can help fill in my memory, please say hi.

Got up early for some healthy debate on the differences between Bazaar and Git at the DVCS Bof. Maybe the slot was changed when I wasn’t looking, but it turned into a “introduction to Git and Gitorious” presentation, with a packed audience. For a session meant to focus on DVCS in general, and how GNOME can move from SVN to $DVCS, it was a bit of a shame. BUT THEN…

There was a second smaller talk on DVCS that was slightly more productive. Neither side has managed to provide an action plan so far. When the Bazaar and the Git advocates can come to GNOME and say “we have a plan, this is how we are migrating and this is how we are going to fix all the systems that depend on GNOME”.. then we can talk. This whole issue needs some JFDI - we can’t cry/shout until our DVCS is picked, and then expect the sysadmins to take care of it.

On a lighter note, got some swag. Quite happy with the laptop bag, and the T-shirt is quite nice. Doesn’t match the codethink t-shirts though

Now back to cleaning up the Git code so Rob doesn’t harm me.

Setting off for the airport soon. I arrive with codethink somewhere around 2AM local time on Sunday.

Looking forward to seeing John Stowers and maybe getting some Conduit hacking done. It would be cool to see some of the build brigade people and see if we can get build.gnome.org running the newest buildbot code, with a single master (instead of one per project). Theres a chance i’ll have to talk about libgitcore, and the joys horrors of Git coding. Oh and the scary DVCS discussion. It will be interesting to see who wears both a “I use Bazaar lots” *and* a “I use Git lots” badge.

And I heard something about whisky…

If there are any veggies or vegans coming, be sure to poke me and say hi, we can go track down some carrots together Jc2k on IRC, or comment here. Failing that, look out for codethink t-shirts - I won’t be far away.

Always, always, always remember to

git-rebase --continue

Or strange confusing things happen, and if you don’t have experts on hand… FAIL.

(Needless to say, the silly little typo I was trying to rebase away made it into public history after all. Poo.)

TWIB blogged about a little something we have been working on with the Bazaar guys. The Bazaar mirror now has loggerhead and search, based on the bzr-search plugin. This lets it search over the whole history of trunk. When beuno finishes skinning it i’ll integrate it in to the main site. In the mean time, enjoy.

Oh, it also shows off something I badly explained the other day. See here. Revision 5 was committed by myself, but bzr-svn also saved the –author property, attributing that code to Jelmer correctly.

zeenix decided to quote me in a recent blog post. My remark was meant to be a light hearted jibe at our obsession with going over and over the same points but never getting anywhere. I failed, but it looks even worse out of context. So lets try this again.

We have ALL heard how Bazaar is so slow you might actually die of old age before you finish checking out your module, and that Git is so hard and voodoo ridden that you will erase your project from history and cause the universe to collapse if you use the wrong incantation.

Both of these arguments are nothing new. They are both very tired, and of questionable correctness in recent versions of both tools. Thats why I didn’t want to hear about them *again*. That doesn’t mean that they aren’t valid concerns, just that covering them again didn’t seem constructive.

As it happens, zeenix posted about how Git is fast. Now some interesting debate is happening over in the comments of that entry, so maybe my poor sense of humour did some good. Note that I never bothered to try and say Bazaar wasn’t slower because i thought it a waste of time and a good way to get flamed, but the people are now saying “hey, Bazaar is actually doing OK”. Yay.

In closing: people, please don’t get upset, i’d never waste my vodka over something like DVCS-wars! Now if this was vim vs emacs…

Federico wrote a nice post about Git. I just wanted to add a few things to it really.

• If anyone wants to buy me beer for Bazaar mirror, Git mirror, or the Mercurial mirror that people are begging me for then please remember… Spirits, spirits, spirits. (They are especially good at making me forget, which is handy after setting up something like git mirror The stronger the better!) 
• git-mirror.gnome.org does not make git.gnome.org any easier. It just makes it easier to try out git-svn on a GNOME project. (Some/all of these may be fixable with surgery, but the one way conversions will likely be quicker anyway).
  • The main reason is of course the polluted logs (filled with git-svn rev id metadata). I would resist any module having a Git repo with such ickyness in its history.
  • I didn’t have the data to provide git-svn with an authors lookup
  • What to do about the references to svn in git-mirror? All the branches have an svn/ prefix…
  • git-mirror ignores Bazaar metadata. Thats right folks, it says svn.gnome.org on the tin but the Bazaar users have already started upgrading GNOME to Bazaar with bzr-svn. Check out this. You’ll notice how commits made with Bazaar are somehow “better” than their SVN counterparts. When I apply someones patch with bzr-svn I log who it is from using the –author property. I want this preserved.
• The git mirroring process uncovered bugs in git-svn, despite its heavy use by the core GNOME hackers. Even one on GTK+, which is meant to be the thing that everyone makes a mirror of! So we will likely break other git import tools too. This is true of any DVCS, so my point is really “its never going to be ‘easy’ to ditch SVN”.

Lets show a bit of even handedness and community and not make choosing $DVCS like chosing $EDITOR. Git people, please try out bzr-mirror. Especially merging and branching stuff. Unlike git-svn, you can use bzr-svn as though its a normal, full blown DVCS. Blog about your experiences, let the Bazaar developers what they need to work on. (I will spit my vodka in your eyes if all you come up with is speed). Likewise, the Bazaar folks should try out git-mirror and see if its as good as they say, and tell them which bits of the UI need fixing. What do you find yourself missing?

Mercurial people: Take me to your documentation! What is the standard way to make a Mercurial “mirror” of SVN?

In the next few days I should be taking the lid off a loggerhead instance for bzr-mirror. Of interest is the search, which uses a full text index created by the wonderful bzr-search plugin. It’s pretty impressive.

As I’ve blogged before, the mirrors update in response to the svn-commits mailing list. This means that we don’t have to hammer 520 GNOME modules on a hourly basis. It also means we are nearly always up to date. I’ve tweaked the script that manages this:

• Previously, the script would only do updates of existing modules. But now it will automatically mirror new modules the first time something hits the commits list for them, for both Bazaar and Git
  • For git, a new clone is created. It is repacked. Various config settings and symbolic references and internals are poked.
  • For bzr, we just need to run bzr svn-import. Its not needed, but I also create a full text search index of trunk for later secret fun.
• Updates are now batched. Example: If 3 e-mails arrive together for tracker, that means that svn.gnome.org gets poked 3 times more than needed. So I batch updates together. Faster, cheaper, saner.

You git speed freaks will be pleased to know you can now clone over git://.

cd ~
git clone git://git-mirror.gnome.org/git/conduit
cd conduit
git svn init -s svn+ssh://svn.gnome.org/svn/conduit --prefix=origin/svn/
git svn rebase

Hope you enjoy the extra speed ;-