Posts Tagged ‘GNOME’

Is speed the only reason?

Thursday, June 26th, 2008

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…

The mirror man says

Thursday, June 26th, 2008

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 :P 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.

git-mirror.gnome.org

Saturday, June 21st, 2008

As most of you know, I run bzr-mirror.gnome.org in my spare time. This was to allow people to try out the awesomeness of Bazaar as easily as possible. As much as I love Bazaar, certain outside forces mean that I sometimes have to use Git. So a few weeks ago when no one had approached bkor to set up git-mirror.gnome.org, I decided I would.

The plan:

  • Follow the example in the git-svn manual, 520 times
  • Run the equivalent of “bzr pull” everytime a commit happens (yay svn-commits-list)
  • Throw gitweb at it
  • Profit

All in all it went OK. Here are some things I encountered.

  1. I converted conduit, f-spot, tomboy and a few larger modules like gtk+. Then I tried to clone them over http. Found out I have to call git-update-server-info in post-update hook. This is well documented, and no big deal, but a surprise as its not needed with Bazaar.
  2. My initial attempt was cut short by James, who spotted I was missing an important argument (–rewrite-root) in my git-svn cloning. I had to abort the import after 3 days. Rip up and retry. Or so we thought. After some talking in #git, we found that –rewrite-root http://anything works, making me wonder why the root URL is stored in the log at all.
  3. When I ran the import again I found some of the modules randomly aborted mid conversion. It was able to resume them manually – yay, because it was one of the bigger modules the first time (gimp).
  4. I also found that gitweb wasn’t showing the tags and branches. James saved me again, this time with a script from Tim Janik at Imendio. Its full of perplexing git incantations, but works perfectly. It has to run after each change to keep everything up to date.
  5. I couldn’t get git-svn to work on a clone. My hero James was MIA, and I was struggling. A trip to #git offered mixed results. There were patches, there were more perplexing git incantations. Nothing seemed to work. With Robs help we got it working, and when James returned we got it working with branches and tags too. Day was saved. HeroPoints++.
  6. My version of git-svn chokes on accerciser and fast-user-switch-applet. My hero might yet fix this one too, as his git-svn was able to convert the problematic tags (this is due to cvs2svn).
  7. Now the mirror is ticking along, but gtk+ won’t update properly. I can update it from a local rsync, but not over http. I get “Apache got a malformed URI: REPORT request failed on ‘/svn/gtk+/!svn/vcc/default’: Unusable URI: it does not refer to this repository at /usr/bin/git-svn line 3833″.
  8. gnomemm Uses a non standard layout (at least in GNOME terms) which git-svn doesn’t like that much, so I will have to special case it in my scripts.
  9. I still have to go back and repack all the repositories as git-svn generates packs that are excessively large, and git gc –prune –agressive isn’t enough (thanks to Pieter for this advice).

After a week of churning its nice to have my server back to normal load. I still have to try and skin gitweb so that it looks GNOMEy and there are a hundred and one other things bothering me, but now you guys can:

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

I’m not sure what will happen if you pull from the mirror and from svn.gnome.org. That is the ideal use case IMO (should be faster for you as mirror does the conversion for you). If someone wants to try and let me know how it handles it…

Want a mirror for your $dvcs? Ping me, maybe i’ll give it a go.

Bazaar: The shiny shinyness

Tuesday, June 17th, 2008

Did I get your attention? :-) This is just a shout out to let you all know about #gnome-bzr (on irc.gnome.org). If you use Bazaar for your GNOME project, or are thinking of using it, please pop in. You might just get a first look at some of the shiny, shiny things we have in the cooker and that the bzr team are helping us try out. I’ll also be able to help you out with any bzr-mirror related questions, and bzr-svn in general.

We have a few people from #bzr kicking around in there too, feel free to poke them with feature requests. Poke well, we don’t like letting them sleep too long..

What a month

Saturday, June 7th, 2008

Lots of cool things going on. I’ve been name dropped by bkor and jcastro. A few weeks back I went in to York and met pvanhoof, learning much about Belgian politics :-) The following Monday I met robtaylor. We talked about Git, libgitcore, wizbit and Conduit. A few days after that sabdfl called me! He tells me a lot of people have been talking about the Bazaar mirror of GNOME that i set up (bzr-mirror.gnome.org) and he wanted to talk about it.

Woot for meeting new people, and some of my heroes to boot, within GNOME and Ubuntu :-)

    Conduit in GNOME SVN

    Wednesday, November 28th, 2007

    So Conduit has moved to GNOME SVN at last :-D If you are running SVN conduit, you can now get your fix from:

    http://svn.gnome.org/svn/conduit/trunk

    This is great news for Conduit, and will hopefully help us spread the syncable desktop vision throughout GNOME and the free desktop in general.

    Gimmie my utopia!

    Wednesday, April 4th, 2007

    Alex, just wanted to throw in my thoughts as an outsider.

    I like to keep up with the developments in the free and open source software world. I track a fair few blogs and planets and wade through around 80 posts a day in my aggregator (maybe more). In that time i’ve read a lot about gimmie. I was impressed. I tried it, and was even more impressed! Despite hearing lots about Gimmie, I haven’t heard anything about BigBoard. And it would seem it’s developers are just as much a part of “Planet Gnome” as yourself? Anyway, I just wanted to say that I can’t wait to see what happens in Gimmie next :-)

    The discussions about accessing web services made me consolidate a few points i’ve have for a while and i’d like to share with you (and the community in general). On the desktop we have lots of data we want to share, to sync, to, well, use!

    • Banshee has to learn how to talk to each type of MP3 player to sync it’s library
    • So does Rhythmbox, but in a different language.
    • Beagle and Tracker have to learn how each application stores its data so you can search it
    • Gimmie has to learn how to talk to generic web app X, Y and Z and how to get any interesting and relevant desktop data
    • Conduit is a sync tool and so has to do all this and some more!
    • Tomboy wants to be able to sync too

    I think it’s great how useful these applications are, but I think a lot more could be done to share data. It’s not really about whacking together a library so two apps can talk to an iPod. That’s bad because each app using it has a layer of glue to link it in to their plugin system. I think instead we as a community need to think in terms of objects that people are using. Have a common way to share a photo between different applications and devices and webservices. Sort of like a higher level VFS.
    My utopian vision then.

    • It would be nice if Tomboy officially used Conduit to do it’s syncing. Right now that means that you would be able to sync Tomboy to any folder that VFS can see, to an iPod and (i believe) BackPackit. And google notebook wouldn’t be difficult. As more dataproviders are developed for Conduit then this list will increase greatly. The todo list includes my network code which would allow Tomboy to Tomboy over the network. The same code will enable F-Spot to F-Spot etc etc. Why reimplement from scratch when we can do this now?
    • More work would be done on the Conduit Web Services stuff and Gimmie would be able to use our DataProvider framework to query these different kinds of sites. And because the DP’s are responding with generic Photo or Contact objects its trivial for Gimmie to handle other DP’s too. The same code could show a Photo from Flickr or a photo from a folder, just need to pick the DP! Because Conduit is in python too then Gimmie could probably directly reference Conduit code rather than going through the DBus API even. If Gimmie can consume one dataprovider, it can pretty much consume them all!
    • Banshee and Rhythmbox would have Conduit plugins so that they can use the Conduit DataProvider framework to work with music devices. This is instead of them writing glue around each generic-music-player-support.so. Conduit would provide one set of glue. Both Banshee and Rhythmbox would then support every DAP Conduit ever does (them ALL >: ).. I dream..)
    • Tracker and Beagle would be able to use our DataProviders to build their indexes. Why have two different sets of glue code for reading the same data out of evolution and f-spot? You can talk about speed I suppose, but I want a desktop that’s integrated. When I want to scrape out every last MhZ out of a box i’ll give Xubuntu a whirl!

    I don’t know how well i’m making my point here. But I don’t see why all of these projects can’t work together more. If they could all pass around these common desktop objects then surely everyone would benefit?