Rubygems mirror

If you’re a RubyGems user, you can’t have missed how slow it is, even with the new mirroring system.

To speed it up a bit for me, I setup a mirror. You’re free to use it for your own needs if you find it speedier, here’s the URLs :


To use it only for a particular gem use :

gem install --source your_gem_name

To set it as the default for your gems add the next line to your ~/.gemrc :

gem: --source 
Published on Sat, 06 May 2006 13:40

Introduction to distributed Version Control System with SVK

VCS such as Subversion or CVS are great but they have a major drawback : when working offline and your server is online, you can’t version your changes until you reach an internet access point.

Here’s where SVK come to your rescue, it’s a distributed (or decentralized as stated on its website) version control system. It works with a under-layer subversion filesystem improved with some useful features, but the interesting part is its ability to play with other VCSs (Subversion, Perforce and CVS) by mirroring them locally and letting you do offline operations on them. Those changes you’ll merge back to remote server when you gain access to an internet connection, but enough with meetings, let’s go to work !

First you need to have a working installation of svk, but I don’t cover this part as it’s specific to each OS, just point you favorite browser to SVK Installation Page and follow the steps corresponding to your environment.

Choose your local layout :

Once you’re done with the installation part, you should start by creating a local svk repository. You have two choices :

  1. A single default repository
  2. Multiple named repository

I choose to go with the first choice, it’s enough hassle to play with multiple remote repositories without having to suffer the pain of searching to which local repository your remote repository belongs. But feel free to choose your way.

Initialize local repository :

svk depotmap --init

This will create the default repository in ~/.svk/local.

As I choose to go with the default repository, it has no explicit name, this assumption will make sense later.

Create an initial layout :

This step is not mandatory, but as I like to keep things as clean as possible, we will create some directories in the default svk repository.

svk mkdir //mirrors -m 'Creating directory for mirrored projects trees'

This line will create a directory called mirrors in root of default svk repository where we’ll put mirrored remote projects trees. Here’s where the no explicit name assumption come to play : the root of default svk repository is access using //, if we had chosen to go with multiple named repository, it’d be /repository_name/.

svk mkdir //local -m 'Create directory for local projects changes'

Let’s create another directory, this time to store local changes, be it local branches of some mirrored projects or simply local projects you want to put under version control.

Mirror your first remote project :

I’ll use a remote subversion repository accessible through Apache’s mod_dav_svn module, but SVK works well with others svn access schemes svn:// or svn+ssh://, without mentioning perforce and cvs.

svk mirror //mirrors/blogmarks -m 'mirror of blogmarks trunk repository'

This line will instruct SVK it has to handle a mirror of the remote repository at in the //mirrors/blogmarks local repository.

Then to checkout the entire tree of the mirrored project in local repository :

svk sync -all


svk sync //mirrors/blogmarks

The last commands start a synchronization between all mirrored remote repository (--all) or a specific one only (//mirrors/blogmarks) and the local repository.
Wait for svk to be done and you’ll have a copy of the remote tree in your local machine.

Make a branch for local work

This part is especially useful for mirrored repositories where you don’t have commit rights, but it’s a good habit for repositories where you have rights access too.

svk cp //mirrors/blogmarks //local/blogmarks -m 'create a local dev branch'

Now your repository would looks like :


Checkout a copy :

Now we’re able to checkout a copy of the new branch to handle our development.

svk co //local/blogmarks BlogMarks

This give us a BlogMarks directory in the current folder which is a working-copy of //local/blogmarks

Now let’s hack your code !!

Commit modifications :

When you’ve implemented you’re next killer feature and want to track the modifications to go on with the next one, in the working-copy directory, issue a :

svk ci -m 'Implements a killer feature'

Merge your changes back to the main remote repository :

If you have write access to the repository, you’ll surely want to send your modifications to the remote server when you gain access to internet. This is another great added feature of SVK.
First be sure to have the latest version for your mirrored project :

svk sync -all


svk sync //mirrors/blogmarks/

Then issue a smerge :

svk smerge -Il //local/blogmarks/ //mirrors/blogmarks

... Follow direction provided on screen by svk ...

Options -Il ensure each modifications you did will be committed individually to the repository (I) using commit log provided when committing to svk (l).

Generate a patch :

In case you don’t have write access to remote repository, perhaps do you want to send developers a patch with your modifications. SVK to the rescue(be sure to re-sync your mirrored repository before generating the patch).

As always there a numerous ways to do that, but I found the Scott Laird ‘s way is really clean, so we’ll go with that.

Create a new directory to handle patch-set :

svk mdir //patchsets

Then copy your project trunk (or branch) :

svk cp //mirrors/blogmarks //patchsets/blogmarks-withkillerfeature

Now merge your change to the patch-set, let’s assume we had changes about our killer feature in changeset 110, 119 and 120 :

svk merge -l -c 110 //local/blogmarks //patchsets/blogmarks-withkillerfeature
svk merge -l -c 119 //local/blogmarks //patchsets/blogmarks-withkillerfeature
svk merge -l -c 120 //local/blogmarks //patchsets/blogmarks-withkillerfeature

Then generate the patch :

svk diff //mirrors/blogmarks/ //patchsets/blogmarks-withkillerfeature

Here it is, a shiny patch ready to be send to developers with write access.

Here it is for this introduction.

Published on Sat, 04 Mar 2006 16:00

BlogMarks Ruby Library

As said in title, I’m working on a ruby library to interact with API and I just release the first beta version (0.1.0).

This project amongst others is available on my projects dedicated website : Jonathan’s Projects, as well as on RubyForge under the name blogmarks. Publishing the project on rubyforge is a great thing because it will be automatically published on their gem server.

I don’t really know how many time it take for a new gem to be integrated in gem server, but as soon as it will be, you’ll be able to install it via :

sudo gem install blogmarks

As you should see on my projects page (and soon on this page), I did a simple Typo Sidebar to show how one can use the library to display his last BlogMarks.

Published on Mon, 30 Jan 2006 11:33

Prototype's Shortcuts

Prototype is a wonderful javascript library written by Sam Stephenson.

The more I use it, the more I love it, it makes writting javascript so less painful.

This post is the first of a series aiming to discover its

So let’s start with the lovely shortcuts provided by Prototype.

Shortcuts are functions whose names are as concise as possible, mostly 1 or 2 letters and wrap some of the most repetitive tasks you end up to write when doing javascript.

Published on Fri, 20 Jan 2006 11:17

Ouverture / Opening

Bienvenue, j’ai enfin installé quelquechose sur ce nom de domaine qui trainait depuis trop longtemps.

Il y aura donc ici désormais ici un devlog, contenant mes liens et petites trouvailles concernant le développement web ( ROR, PHP, JavaScript) et Mac (Cocoa). De plus j’essayerais de discuter de temps à autre d’IHM(Interface Humain Machine) et d’accessibilité.

Pour la partie techno du site :

Welcome, I finally installed something on this too long sleeping domain.

From now on, there will be a devlog here, talking about web ( ROR, PHP, JavaScript) and Mac (Cocoa) development. Additionally, I will try to discuss HCI and accessibility from time to time.

Technically speaking, this site run on :

(The english part of this site will help me improve my english skills, which really need it. So feel free to correct me about erroneous sentences and terms)

Published on Tue, 17 Jan 2006 21:53