Thu 2008/Jul/03

• Mario Ðanić has another interesting post about distributed version control systems. He proposes that each developer (or at least, every maintainer) could use the DVCS of their choice, but then we could have a common web/collaboration interface to all the DVCSs.

• My current favorite way of developing against a stable release:

  $ cat ~/bin/make-nautilus
  #!/bin/sh
  module_name=nautilus
  diff_name=~/suse/11.0/src/SOURCES/nautilus-document-centric.diff
  anchor_name=OPENSUSE_11_0_PATCHES
  branch_name=document-centric
  cd ~/src/$module_name
  git diff $anchor_name..$branch_name > $diff_name
  cd ~/suse/11.0/src/SPECS
  if rpmbuild -ba $module_name.spec
  then
      cd ../RPMS/i586
      gnomesu rpm -Uvh --force *$module_name*
      notify-send -t 0 "$module_name is installed now"
  else
      notify-send -t 0 "$module_name doesn't build!"
  fi

Syndicated 2008-07-03 11:29:00 (Updated 2008-07-03 20:04:30) from Federico Mena-Quintero - Activity Log

Thu 2008/Jun/26

• John says:

  The main reason [why git-mirror.gnome.org doesn't make git.gnome.org any easier] 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.

  This is a non-issue. Ruby on Rails used to be hosted on Subversion, and then it switched to Git. To do the conversion, they simply used git-svn. You can do "git clone git://github.com/rails/rails.git", then "git log" and search for "git-svn" in the output in order to find the git-svn metadata.

  You'll see this:

  ... git-based development goes here ...
  
  commit 67022671bfa28d5675a30925a8d1e271c576f4d2
  Author: David Heinemeier Hansson <david@loudthinking.com>
  Date:   Thu Apr 10 22:09:13 2008 -0500
  
      Testing commits
  
  commit ed99dda174da439a0947cdabea3babf027c672ac
  Author: Rick Olson <technoweenie@gmail.com>
  Date:   Thu Apr 10 18:06:05 2008 +0000
  
      Change validates_uniqueness_of :case_sensitive option default back to true (from [9160]).  Love your database columns, do
  n't LOWER them.  [rick]
      
      git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@9248 5ecf4fe2-1ee6-0310-87b1-e25e094e27de
  
  ... svn-based development went here ...
  	    

  So, in the commit logs, you have everything since $beginning_of_time until $switchover_date with the git-svn-id strings, and everything after that without any such garbage, as would be normal for "plain" git repositories.

  Having that metadata in the log actually provides valuable information.

  If you have to do code archaeology (which Eric Sink calls "traceability"), then the commit log will tell you when the svn->git switchover occured. Before that point, you know that any branches are dead-ends and merges are funny (svn didn't handle them).

  You'll know that before the switchover point, information about code attribution will not be 100% clear, as you couldn't specify --author in an svn commit (so you'll perhaps have to look at the actual ChangeLog and hope that the committer was kind enough to say "original patch by $author").

  When you do a conversion between revision control systems, you keep the old system around in read-only mode for if anything goes wrong. It's nice to know that if we ever need to check something in the original SVN repository, we'll have the SVN revision numbers from the git-svn metadata.

  Finally, the git-svn strings in commit logs will disappear really quickly from your everyday view. They just appear further and furter back in time, and you seldom look at those commits, anyway.

• Mario Ðanić has been investigating about adapting Gitorious for KDE. He says he would be happy to talk to people who would like to adapt Gitorious for GNOME's needs as well. Among other things, Mario is working on the Summer of Code to write a GNOME client for the openSUSE build service.

Syndicated 2008-06-26 10:55:00 from Federico Mena-Quintero - Activity Log

Wed 2008/Jun/25

• Git-mirror.gnome.org is AWESOME and John Carr deserves large amounts of beer for it. The git-mirror has already saved my ass twice this week ("Where is this patch in trunk? Was it backported to the stable branch?"). Now that we actually have full Git repositories of GNOME, we could easily move to using Git for everything.

  Søren, Bryce, James, and myself had a pretty productive time hacking on support for RANDR 1.2 in gnome-desktop, gnome-settings-daemon, and gnome-control-center, all in Git repositories.

  Gitorious is like a free version of Github: you can create public Git repositories in a central server, push to them, and monitor who clones your repositories. Later those people can inform you, "I have some cool stuff in my repo; you should fetch those changes from it". Or you can say the same to them, and Gitorious/Github will notify the people in question. This is far, far more productive than monitoring an svn-commits-list or similar.

  Gitorious is hosted in a Gitorious installation itself, so you can of course "git clone" is source code. It would be reasonably easy to use this in GNOME's infrastructure, and it would automatically let module maintainers communicate better with contributors (and allow contributors to play with experimental branches without disrupting the maintainer's work).

• ... Which reminds me, if you are tired of wasting your time with Subversion, be sure to attend the BoF on distributed version control systems at GUADEC, where Behdad and yours truly will delight you with our widely-acclaimed acrobatic act.

Syndicated 2008-06-25 12:37:00 from Federico Mena-Quintero - Activity Log

Tue 2008/May/20

• This year I am mentoring two students for the Summer of Code:

  Andrei Soare is working on measuring memory fragmentation in the GNOME libraries. The idea is to find the main culprits for fragmentation, and see what we need to do to fix them (use more stack allocations? provide substring APIs that can take a buffer and a length, instead of g_strdup()ing temporary crap everywhere? use flat buffers with pointers into them for static structs rather than structs full of pointers to individually-allocated sub-buffers?). Andrei's code is available as a Git repository. So far, he has a modified version of of Stefan Kost's bprof, suitable for use with Stuart Parmenter's memview. Andrei has found a few bugs where we do things like using g_free() on a malloc()ed buffer, or vice-versa. I hope he starts blogging his first fragmentation plots soon.

  Stanislav Slušný is working on profiling the calendar in evolution-data-server, in particular the engine for live queries. The query engine is very simple; it just iterates through all the items in a calendar and returns the items that match the query. We think that most queries are of the form, "give me all the items in $date_range", so the query engine could use a smart data structure like an interval tree to avoid scanning all the items. So far, Stanislav has added a logging mechanism to evolution-data-server so that we can see which queries get performed (by Evolution itself, the panel's clock applet, and various things across the desktop), and how long the queries remain active. This is available in a Git repository. Stanislav showed me a couple of pretty sexy plots of query lifetimes; let's hope he blogs about them soon.

Syndicated 2008-05-20 21:02:00 from Federico Mena-Quintero - Activity Log

Tue 2008/Apr/22

• And now for a gratuitous baby picture.

  

Syndicated 2008-04-22 10:50:00 from Federico Mena-Quintero - Activity Log