Mercurial : Publier sur plusieurs dépôts

Le problème

Vous avez plusieurs dépôts Mercurial, en général un principal et un miroir (pour la sauvegarde). Cependant, toujours garder les deux dépôts synchronisés n’est pas toujours une mince affaire.

Une solution

Ayant fait fasse au problème ci-dessus il y a peu, j’ai cherché une solution qui pourrait le résoudre. Impossible cependant, de mettre la main sur quoi que ce soit. J’ai donc décider d’écrire ma première extension pour Mercurial. Voici hg-publishall. Une extension simple qui rajoute une commande à l’outil hg : pushall. Lors de son exécution, l’extension va lire le fichier .hg/hgrc du dépôt et y récupérer tous les éléments dans [paths], et pour chaque va effectuer un hg push <url_du_depot>.

Installation

Récupérez la dernière version du script : hg-publishall (trunk). Décompressez l’archive et déplacez le script publishall.py là où vous placez vos extensions Mercurial (chez moi c’est /Users/thomas/Library/Mercurial/). Pensez à le rendre exécutable par le ou les utilisateurs qui vont utiliser le script (chmod +x publishall.py sous Linux/BSD).

Vous devez ensuite configurer le dépôt qui va bénéficier de cette extension :

Soit le dépôt ~/depot-test/, j’ouvre le fichier ~/depot-test/.hg/hgrc et le modifie comme suit :

[paths]
default = ssh://server.localnet/depot-test/
bitbucket = https://:<user>:<pass>@bitbucket.org/<user>/depot-test/

[extensions] publishall = /Users/thomas/Library/Mercurial/publishall.py

Votre dépôt est maintenant configuré pour utiliser l’extension hg-publishall; et il sera publié sur deux autres dépôts : default (un dépôt sur le serveur du réseau local) et bitbucket (notez au passage que l’authentification sur les dépôts distant est exactement la même qu’ailleurs dans Mercurial).

Utilisation

Rien de bien compliqué. Toujours dans ~/depot-test/, après y avoir travaillé un peu comme vous en avez l’habitude, il suffit de taper :

$ hg pushall
Et c’est parti, les modifications que vous avez effectué sur le dépôt vont être publiées. Pour information : vous pouvez aussi utiliser hg pusha, qui est un alias à hg pushall.

Conclusion

Amusez vous bien, et n’hésitez pas à faire remonter tout ce que vous pouvez !

Posted in None at October 23rd, 2009. Comments.

FreeBSD : serveur web Lighttpd

Je pars ici sur le fait que vous avez d’une part, les bases d’utilisation d’une FreeBSD (ou de n’importe quelle autre *BSD, voir distribution Linux) et d’autre part un système FreeBSD récent (7 series actuellement) installé, fonctionnel et connecté à internet.

Servir pour le web

Pour cela, vous devez déterminer quel serveur web remplira cette tache pour vous. Chacun ses choix, chacun ses arguments. Je choisi ici d’installer Lighttpd (a.k.a. Lighty), car il convient parfaitement à mes besoins et est simple pour une utilisation standard.

Je couvrirais ici son installation et sa configuration pour l’utilisation suivante :

Rien de bien sorcier, le tout étant d’être méthodique et de prévoir dès le départ où on veut aller.

Lighty

Rien de bien compliquer dans l’installation de Lighty par les ports :

$ cd /usr/ports/www/lighttpd

make install clean

Normalement, les options de compilation pour Lighty doivent vous être demandées. Voici celles que j’ai choisi :

Options de compilation Lighty

Options de compilation Lighty

Normalement, l’installation devrait se dérouler sans trop de problème. Ajoutez maintenant la ligne suivante à /etc/rc.conf :

lighttpd_enable="YES"
Rien d’autre à faire ici. Pour votre information, le fichier de configuration est placé suivant la norme FreeBSD : /usr/local/etc/lighttpd.conf. Pour lancer/arrêter/redémarrer le serveur, utilisez /usr/local/etc/rc.d/lighttpd start|stop|restart. Pour récupérer des infos en cas de soucis, c’est tail -f /var/log/lighttpd.error.log.

PHP5

Là aussi, on va utiliser les ports :

$ cd /usr/ports/lang/php5

make install clean

Rien de très palpitant ici. Il nous faut maintenant installer les extensions PHP voulues, toujours par les ports :

$ cd /usr/ports/lang/php5-extensions

make install clean

Lors de la configuration, la liste des extensions à installer devrait vous êtres demandée. Choisissez celles que vous voulez. Pour info, j’ai choisis celles-ci : ctype, curl, dom, gd, imap, mbstring, mcrypt, mysql, mysqli, pcre, posix, session, simplexml, xml, xmlreader, xmlrwriter, zlib.

A la fin de l’installation, ouvrez le fichier de configuration de Lighty et effectuez les modifications suivantes :

  • Dans la liste server.modules, dé-commentez mod_fastcgi.
  • Descendez et dé-commentez le bloc relatif à fastcgi.server :
    fastcgi.server = ( ".php" =>
                             ( "localhost" =>
                                  (
                                   "socket" => "/tmp/php-fastcgi.socket",
                                   "bin-path" => "/usr/local/bin/php-cgi"
                                  )
                             )
     )

Enregistrez et relancer Lighty. PHP est maintenant opérationnel (vous pouvez tester avec un <?php phpinfo(); ?>).

Django

C’est ici la partie qui m’intéresse le plus.

Premièrement, installez Django (notez que ceci n’est qu’une façon de faire) :

$ cd /usr/ports/devel/py-setuptools

make install clean

/usr/local/bin/easy_install django

OK. Bon, dans mon cas, j’ai une application située dans /storage/www/thomas/, qui sera accessible depuis le web par http://thomas.pelletier.im/. Adaptez suivant vos besoins.

  1. Créez un dossier public dans /storage/www/thomas/.
  2. Adaptez et placez-y le fichier lighty.sh suivant :
    #!/bin/sh
    app_path='/storage/www/thomas/'
    p='/tmp/thomas-django.pid'
    cd "$app_path"
    if [ -f $p ]; then
     kill $(cat -- $p)
     rm -f -- $p
    fi
    
    exec /usr/bin/env \
     PYTHONPATH="$app_path/.." python \
     manage.py runfcgi \
     daemonize=false \
     method=prefork \
     maxspare=2 \
     pidfile="$p"
  3. Rendez le exécutable par www :
    $ chown www:www lighty.sh
    $ chmod +x lighty.sh
  4. Créez un fichier vide django.fcgi dans public/ (pas nécessaire je pense, mais ça marche pour moi).
  5. Ajoutez le bloc suivant à votre ligtttpd.conf :
    $HTTP["host"] == "thomas.pelletier.im" {
            server.document-root = "/storage/www/thomas"
    
            url.rewrite-once = (
                    "^(/.*)$" => "/public/django.fcgi$1",
            )                    
    
            fastcgi.server = (
                    ".fcgi" => (
                            "django" => (
                                    "socket" => "/tmp/thomas-django.socket",
                                    "bin-path" => "/storage/www/thomas/public/lighty.sh",
                                    "check-local" => "disable"
                            )
                    )
            )
    
    }
  6. Enregistrez et relancer Lighty.

Normalement c’est bon, votre projet Django est maintenant servi par lighty !

Mercurial

NB : je ne vais pas entrer dans les détails de la configuration d’un dépôt mercurial.

Il existe plusieurs moyens de servir des dépôts mercurial. J’ai choisis hgwebdir. Le site officiel détail l’installation en CGI. Je trouve ça dommage. Pour ma part, j’utilise ici FastCGI.

Je pars du fait que vous avez vos dépôts déjà configurés et fonctionnels dans /mesdepots/ et que vous avez deux dépôts : un publique : “helloworld” et l’autre privé “myproject”.

Pour la petite histoire, helloworld sera accessible en lecture ET écriture par tout le monde. C’est fait exprès, à but purement pédagogique. myproject lui, n’est accessible en écriture et en lecture uniquement par vous.

Premièrement, créez un dossier hg dans /mesdepots/. Placez-y le fichier hgwebdir.fcgi suivant :

#!/usr/bin/env python
#

An example CGI script to export multiple hgweb repos, edit as necessary

adjust python path if not a system-wide install:

import sys

sys.path.insert(0, "/path/to/python/lib")

enable demandloading to reduce startup time

from mercurial import demandimport; demandimport.enable()

Uncomment to send python tracebacks to the browser if an error occurs:

import cgitb

cgitb.enable()

If you'd like to serve pages with UTF-8 instead of your default

locale charset, you can do so by uncommenting the following lines.

Note that this will cause your .hgrc files to be interpreted in

UTF-8 and all your repo files to be displayed using UTF-8.

#

import os

os.environ["HGENCODING"] = "UTF-8"

from mercurial.hgweb.hgwebdir_mod import hgwebdir from flup.server.fcgi import WSGIServer

The config file looks like this.  You can have paths to individual

repos, collections of repos in a directory tree, or both.

#

[paths]

virtual/path1 = /real/path1

virtual/path2 = /real/path2

virtual/root = /real/root/*

/ = /real/root2/*

#

[collections]

/prefix/to/strip/off = /root/of/tree/full/of/repos

#

paths example:

#

* First two lines mount one repository into one virtual path, like

'/real/path1' into 'virtual/path1'.

#

* The third entry tells every mercurial repository found in

'/real/root', recursively, should be mounted in 'virtual/root'. This

format is preferred over the [collections] one, using absolute paths

as configuration keys is not supported on every platform (including

Windows).

#

* The last entry is a special case mounting all repositories in

'/real/root2' in the root of the virtual directory.

#

collections example: say directory tree /foo contains repos /foo/bar,

/foo/quux/baz.  Give this config section:

   [collections]

   /foo = /foo

Then repos will list as bar and quux/baz.

#

Alternatively you can pass a list of ('virtual/path', '/real/path') tuples

or use a dictionary with entries like 'virtual/path': '/real/path'

WSGIServer(hgwebdir('hgweb.config')).run()

Toujours dans le même dossier, créez et complétez le fichier hgweb.config suivant :
[paths]
helloworld = /mesdepots/helloworld/
myproject = /mesdepots/myproject/

[extensions] hgext.highlight=

[web] style = monoblue allow_archive = bz2 gz zip baseurl = /hg/ pygments_style =

Dans le fichier .hg/hgrc de myproject, ajoutez les paramètres suivant dans le bloc [web] :
allow_push = monutilisateur
allow_read = monutilisateur
Vous allez maintenant devoir créer le fichier contenant les comptes virtuels (ie : les utilisateurs mercurial ne sont pas des utilisateurs système). Créez le fichier /mesdepots/hg/passwords et ajoutez une ligne par utilisateur (vous pouvez utiliser des outils en ligne pour générer les lignes à rajouter). Pensez que dans l’exemple, le nom d’utilisateur est monutilisateur.

Editez le fichier /usr/local/etc/lighttpd.conf en l’adaptant à vos besoin : ici, les dépôts sont accessibles depuis http://monsite.com/hg/.

$HTTP["host"] == "monsite.com" {
    server.document-root = "/mesdepots/"
    server.follow-symlink = "enable"
    fastcgi.debug = 1

url.rewrite-once = (
    "^/hg(.*)" =&gt; "/hg/hgwebdir.fcgi$1",
)

$HTTP["url"] =~ "^/hg/" {
    dir-listing.activate = "enable" 

    # My Private repositories
    auth.debug = 2
    auth.backend = "htpasswd"
    auth.backend.htpasswd.userfile = "/mesdepots/hg/passwords"
    $HTTP["url"] =~ "myproject/" {
        auth.require = ( "" =&gt; (
                "method" =&gt; "basic",
                "realm" =&gt; "This is a private repository. If not allowed, go fuck yourself.",
                "require" =&gt; "valid-user"
            )
        )
    }

    # Global config

    fastcgi.server = (
        ".fcgi" =&gt; (
            "hgwebdir" =&gt; (
                "bin-path" =&gt; "/mesdepots/hg/hgwebdir.fcgi",
                "socket" =&gt; "/tmp/hg.socket",
                "check-local" =&gt; "disable",
            )
        )
    )
}

}

Définissez l’utilisateur et le groupe www comme propriétaire du dossier /mesdepots/hg (chown -R www:www /mesdepots/hg). Donnez enfin les droits d’exécution à hgwebdir.fcgi (chmod +x /mesdepots/hg/hgwebdir.fcgi) et redémarrez votre lighty.

Posted in None at October 17th, 2009. Comments.

Progression de LifeDo

Voilà, c’est juste pour annoncer que sous peu je vais pouvoir lancer une mise à jour majeur de LifeDo (elle a beau être majeur, elle n’est pas pour autant une révolution pour l’utilisateur, la plupart des changements sont des optimisations interne et la création de l’API).

En tout cas, c’est de plus en plus un bonheur de coder avec Django. J’ai honte de regarder mon code d’il y a quelques mois, je me demande comment j’ai pu faire pour êcrire des trucs pareil !

Ah sinon, comme l’a signalé benoitc sur IRC, Google Code se met enfin à Mercurial ! Je déteste SVN (système de dépôt de source que Google Code utilisait jusqu’à maintenant) donc je ne voulais plus héberger de projets là-bas. Je ne pense pas migrer vers Google-Code pour mes sources. J’irais peut-être y faire un tour quand mes dépôts bitbucket seront pleins !

Posted in None at April 25th, 2009. Comments.

Quelques infos

Bon, c’est pas vraiment utilie pour la plupart des gens mais bon.

LifeDo à l’air de marcher pas trop mal. J’vais essayer de chiffrer tout ça avec Google Analytics et quelques sondages. J’ai rajouté un petit script aux KTools. Il s’agit en fait d’un court programme pour récupérer tous les fichiers .tex et .pdf d’un certain site web. Il est à usage très spécifique et ne va donc probablement survire à personne, mais je le laisse comme mémo (comment récupérer un fichier, la fonction slugify etc…). Décidément, il faut vraiment que je trouve un moyen d’augmenter mon espace web… Ah aussi, je tests plusieurs moyens de gérer un site web. Au niveau sources j’entends. Je pense qu’un de ces jours je vais faire un compte rendu de toutes les méthodes que j’ai essayé. Si j’ai le temps. En parlant de temps, il faut que je refasse ce blog. Encore des choix en perspective !

Il y a des choses qui changent, et d’autres qui ne changent pas…

Posted in None at April 18th, 2009. Comments.

Modifications des dépôts

Comme vous pouvez vous en rendre compte, hg.kiznet.fr ne renvoi plus vers mes dépôts locaux, mais vers ceux résidant chez BitBucket. En effet, j’ai choisis de déplacer mes sources vers BitBucket afin de disposer de plus de fonctionnalités (issues tracker par exemple), d’une meilleure interface (rien à voir avec le thème GIT de mercurial) et surtout de faire respirer mon hébergement web.

Cependant, les versions actuelles de mes projets tournent sur versions.kiznet.fr. A partir de maintenant, les sources présentent sur ce dépôt sont celles en fonctionnement (en gros, seules les milestones seront mises en ligne).

Posted in None at April 13th, 2009. Comments.

Dépôt mercurial pour Djangoproject

Je viens de tomber par hasard sur un dépôt mercurial semblant être effectivement un dépôt officiel, servant de miroir au dépôt principal. Information à vérifier.

Voir le dépôt.

Posted in None at January 20th, 2009. Comments.