dimanche 31 juillet 2011

Gitolite / Mercurial server

Lately I installed 2 similar tools : gitolite and mercurial-server.
The 2 tools achieve the same goal, managing a central repository handling remote virtual users and differ mainly on the dscm they target (as their name imply).

As a matter of taste, I tend to prefer git (and so gitolite) beccause of its wider users base and architecture's simplicity.

But mercurial has roughly the same potential, and depending on your context you might prefer (or 'have to' in my case) to work with it.

But before discussing their benefits, let's detail how to install step-by-step :

For gitolite

#apt-get install gitolite

The following NEW packages will be installed:
  git gitolite libcurl3-gnutls liberror-perl rsync

A gitolite or git user will be created in the process, for the rest of the document I assume this user to be 'gitolite'.
(this is the case on debian and ubuntu)

Some people prefer to create a gitolite admin dedicated user, but I prefer to reuse and existing user :

su -  noc

This user has to create a ssh key (without passphrase) if he doesn't already have one.

cp .ssh/id_rsa.pub /tmp/noc.pub

su - gitolite

gl-setup  /tmp/noc.pub

su - noc

git clone gitolite@localhost:gitolite-admin

cd gitolite-admin
vi conf/gitolite.conf

        repo    gitolite-admin
                RW+     =   noc

        repo    testing
                RW+     =   @all

Get the deb from :

install dependencies :
apt-get install mercurial

install the deb :
dpkg -i mercurial-server_1.1-1_all.deb

cp /tmp/noc.pub /etc/mercurial-server/keys/root/

sudo -u hg /usr/share/mercurial-server/refresh-auth

creating repo is a mater of cloning to the server
hg clone localrepo ssh://hg@server/reponame

The access rights seems a little bit more cumbersome to me
you can either use the /etc/mercurial/server/keys on the server and the refresh-auth command or
in a similar way to gitolite use the hgadmin repo.
Let's follow this way :


samedi 30 juillet 2011

Why I use gitolite

Whereas github is great for hosting your public repositories, as soon as you want to use many private remote repositories you should consider other options.

First because it's going to cost you some money and because it's always a good idea to avoid scatter your private stuffs on external server (Yes I know, as a google minion I'm not a good example...)

Among the many options to hosts your remote git repo, I've found gitolite to be the best one to suit my needs, let me explain why :

* I firmly believe in the KISS principle, and the fact that you don't need to use another daemon (it just uses sshd) is very appealing to me. (Other solutions often requiring to setup an apache/Webdav vhosts, git-daemon or whatever)

* Fine-grained access control : gitolite really shines in this aspect
   In addition to the usual  read/write/read&write gitolite provides access  to 'non-fast forward push', branches creation/deletion, write deny and extends the targets to not only repositories but also branches/tags

* It's simple ! It's simple to install, simple to configure. Don't even need to read the doc to understand :

@admins    = arnaud jeff
@team1     = jeff bob
@team2     =  arnaud jeff
        repo    gitolite-admin
                RW+     =  @admins

        repo    testing
                RW+     =   @team1 arnaud

        repo    kronar
                RW+     =   @team1 @team2

* Even if it relies on ssh as a basis for its authentication, it uses virtual users and doesn't require the users to have an account on the server

* It's configuration is versioned, gitolite-admin is a default repo managed by gitolite enabling remote administration through git. The whole gitolite configuration is self-contained.

* Other features you might like (but that I don't use)
     Informational commands (info, expand)
     disable write to git during backup (sysadmins will like this one...)
     gitweb support

jeudi 7 juillet 2011

Module::Build rocks!!!

Yes I know, this module is already four years old and I'm probably the last Perl coder still using ExtUtils::MakeMaker for his modules.

Some experienced friends of mine already told me about it.
(Hello Maddingue, better later than never...)
I knew that I had to use it, but until today I didn't...

For those of you who haven't see the light, here are some reasons why you should switch to it:

_ It's easy (and you should be lazy) => make2build from Module::Build::Convert made the conversion a breeze without requiring to read any doc (ok I've read the doc anyway, but it's beccause I'm curious...)

_ It's powerful (and you should be impatient) => Build testcover and you have a complete test coverage provided out of the box!
(this feature alone is a killer to me, I know you can achieve the same with EU::MM but it is provided by default with Module::Build)

_ It's the state of the art (and you should be hubristic): using tool of the past without any good reason isn't a pragmatic behavior.
Module::Build is more portable, offer more options, and offer an automatic Makefile.PL generation for all the tools expecting one
(to get for free the best of both world)

There are tons of other reasons that you'll find if you read the doc.
Alleviating  SCHWERN's pain (the EU::MM's maintainer) being the most original one to me :-)

Do yourself a favor, just use Module::Build with your modules.