Ainsi qu'il a été annoncé dans la dépêche de sortie de la version 5.4 PHP rejoint le nombre toujours grandissant de projets utilisant Git.

En effet, la nouvelle est tombée, la migration depuis SubVersion/SVN est désormais complète.

Comme beaucoup de projets désormais, le dépôt mis en avant est sur le non-libre github, bien que le dépôt de référence reste sur http://git.php.net

You can clone or fork the source from our GitHub mirror, and we also now support pull requests made via GitHub. The source is also available via git.php.net

Tout comme l'utilisation de github par Linus pour le noyau, il est intéressant de se demander pourquoi cet usage assez massif de services non libres de la part d'équipes de développement pourtant au fait des licences et de leurs conséquences. Une raison serait évidemment plutôt pragmatique (il suffit de cliquer sur les deux liens de dépôt pour comprendre rapidement) et montre que github a su comprendre et pleinement maîtriser les concepts liés au développement utilisant un outil de source décentralisé offrant de nombreuses fonctionnalités, notamment wiki, gestion des demandes, pull request.

Toutefois, des projets tels que Gitorious ou le très prometteur Gitlab existent.

À noter également le lancement de Baregit pour ceux qui souhaitent un hébergement Git de qualité, rapide et surtout sur territoire français et donc non soumis aux lois américaines sur les logiciels.

Pour en revenir à PHP, l'accès au dépôt Git est décrit et une FAQ est également disponible. Notez que contrairement à l'annonce, la FAQ mentionne git.php.net comme dépôt principal. Pour les nouveaux arrivant sur les Distributed Concurrent Versions System (DCVS, Gestion de version décentralisée) notez qu'une page présentant le workflow utilisé est disponible.

Il ne reste plus qu'à espérer que PHP va continuer d'améliorer sa situation notamment concernant les tests unitaires et le processus de release et que Git sera un atout pour cette lourde tâche.

Annoncé avec un peu retard cette fois-ci (toutes mes excuses), voilà le prochain jeudi du libre !

Pour les nouveaux venus qui ne connaissent pas encore, il s'agit d'une conférence organisée chaque premier jeudi du mois, sur un logiciel ou un thème lié aux logiciels libres. Pour mars, ça se passe donc le 1er.

Cette intervention clôturera un cycle de présentations orienté "technique" destiné à présenter les principaux gestionnaires de version décentralisés. Après Git (Git, ou comment donner l'impression qu'on est un super codeur ?) et Mercurial (Mercurial, gestionnaire de version à la portée de tous), nous finissons donc avec Bazaar, logiciel basé avant tout sur l'accessibilité.

Avant que les trolls ne commencent, je sais, il existe beaucoup d'autres logiciels, mais nous ne pouvons malheureusement pas nous permettre d'organiser un cycle d'un an pour faire le tour de tous les gestionnaires. Nous avons donc fait le choix de présenter quelques noms parmi les plus connus, tout en sachant qu'il en existe d'autres.

Fossil est le système de fichiers de Plan9. Ce n'est pas le sujet de cete dépêche.

Fossil c'est aussi un outil de gestion de version décentralisé, DCVS en court. Il est toujours un peu osé, par les temps qui courent, de parler d'un autre DCVS que le très apprécié Git, mais Fossil c'est aussi un peu plus que ça ; un plus qui m'a beaucoup séduit.

Fossil c'est aussi un wiki, un outil de gestion de tickets et une interface Web (et son serveur) dans un seul exécutable. Sans entrer dans les détails, il prend en charge les mêmes fonctionnalités que la plus grande partie des DCVS. Il se veut robuste et fiable, simple, un protocole réseau simple (HTTP) rendu suffisamment efficace pour fonctionner sur une ligne téléphonique 56k et facile d'utilisation (pas de configuration, commande simple). Ça c'est la partie "marketing".

Si la description sonne un peu comme celle de SQLite, ce n'est pas un hasard : Fossil est développé par les mêmes personnes, utilise SQLite pour le stockage et est utilisé comme gestionnaire de versions pour ce projet (et d'autres). Fossil n'est donc pas juste un projet sombre dans un coin du Net.

NdM : merci à Etienne Bagnoud pour son journal.

C'est bientôt début février, et qui dit « début de mois », dit « Jeudi du libre » ! Comme d'habitude, il s'agit d'une conférence organisée par l'ALDIL le premier jeudi du mois, c'est à dire le 2 février 2012.

Cette intervention fait écho au précédent jeudi orienté technique où il était question de présenter Git, autre gestionnaire de version décentralisé (cf. Git, ou comment donner l'impression qu'on est un super codeur ?). Cette fois encore, les développeurs sont clairement visés, avec un logiciel probablement plus facile d'accès.

Gitlab est une application de gestion de dépôts git sous licence MIT. Elle permet d'héberger sur votre propre serveur des dépôts git avec l'interface web offrant tout le nécessaire pour vos projets : navigation dans le code source, suivi des demandes de bugs et d'évolutions (« issues »), wiki, gestion des droits d'accès par équipe, commentaires, notifications, etc.

D'un point de vue technique, c'est une application Ruby on Rails avec les dépendances suivantes : Ruby 1.9, sqlite3, git, gitolite (pour la gestion des droits d'accès aux dépôts git) et pygments (pour la coloration syntaxique du code).

L'équipe développant Gitlab travaille sur le rythme d'une version par mois et la version 2.0 vient juste de sortir. Celle-ci apporte des changements importants : les très attendues « merge requests », un tableau de bord revu, une gestion des permissions plus fines, notamment grâce à la prise en charge de gitolite, des améliorations graphiques, des fils Atom pour les commits et issues, etc.

Comme tous les premiers jeudis du mois, l’ALDIL organise une conférence pour présenter un logiciel libre et son utilisation. L’idée est d’alterner entre des conférences pour le grand public et d’autres interventions beaucoup plus techniques.

Ce jeudi 1er décembre rentre clairement dans la seconde catégorie, puisqu’il vise directement les développeurs avec une question que beaucoup ont déjà dû se poser : « Comment utiliser efficacement Git ? »