Pijul est un système de contrôle de version distribué (DVCS) développé en Rust et publié sous licence GPL v2. Il est basé sur une théorie des patches.

La différence principale entre Pijul et Git est que Pijul fonctionne avec des correctifs (ou patches), là où Git ne fonctionne qu’avec des instantané (snapshots). Une branche dans Pijul n’est qu’un ensemble de correctifs.

Ce mode de fonctionnement offre plusieurs avantages, dont une approche sans doute plus conforme à l’usage intuitif d’un DVCS. À ce stade, si vous avez reconnu le fonctionnement de Darcs, vous vous dites : « oui, mais c’est lent ! ». Au départ de Pijul, il y avait l’idée d’améliorer la vitesse de Darcs, mais de nouveaux algorithmes ont permis de créer un outil différent, extrêmement rapide.

La version 0.12 vient de paraître : même s’il reste sans doute quelques problèmes (notamment sur l’espace disque), cette version est le fruit d’importantes refactorisations et simplifications, et est de ce fait bien plus stable et cohérente que les précédentes ; en particulier, tous les algorithmes sont maintenant prouvables mathématiquement.

À l'occasion de la sortie de la version 0.4 de git-bug, je me suis dit que je pourrai te raconter un peu de quoi il retourne. git-bug est un gestionnaire de bugs distribué intégré dans git.

git 2.9 est sorti le 13 juin 2016. Pour rappel, git est un gestionnaire de version décentralisé, originellement développé par Linus Torvalds pour versionner les sources du noyau Linux. Depuis, ce gestionnaire de version est devenu très populaire parmi les projets open-source, comme en témoigne le succès des plateformes basées sur cet outil, comme GitHub ou Gitlab, ainsi que les projets de toutes tailles auto-hébergés utilisant git.

Dans cette dépêche nous nous proposons de revenir sur quelques-uns des changements apportés par cette version.

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.

L’équipe Tuleap a le plaisir de vous annoncer qu’elle vient d’ouvrir la plate‐forme Tuleap.net à tous les projets libres et open source.

La plate‐forme Tuleap.net, basée sur l’outil Tuleap, hébergeait jusqu’à maintenant uniquement le projet Tuleap en lui‐même. Devant le dernier buzz dans le monde du développement qui ne vous aura pas échappé (Microsoft rachète GitHub), nous avons décidé de nous lancer : on vous accueille tous, avec plaisir et l’on partage cette plate‐forme aux fortes fonctionnalités.

Mise en place d’un mécanisme de snapshot/rollback sur système d’exploitation GNU/Linux avec le système de fichiers Btrfs.

Cet article fait suite à des travaux de mise en place, sur les systèmes que je gère, d’un mécanisme d’instantanés (snapshots) et de retour en arrière (rollback) sur la partition racine. Tout ce qui suit s’applique en principe à une distribution Debian ou dérivées, mais doit être adaptable aux autres distributions GNU/Linux.

Sur les distributions Fedora ce sont les gestionnaires de paquets YUM et DNF qui intègrent nativement les instantanés Btrfs permettant de faire des mises à jour avec possibilité de retour en arrière, assurant ainsi une grande stabilité et tranquillité d’exploitation pour l’administrateur système.

Git-deliver est un système simple et sécurisé sous GPLv3 pour :

• déployer un logiciel sur un ou plusieurs serveurs ;
• vérifier quelle version est sur un serveur, qui l'a livré et quand, et les éventuelles modifications depuis la livraison ;
• partager des configurations de livraison.

Git-deliver s'appuie sur les atouts de :

• Git pour la gestion des versions, le transfert de données et le contrôle d'intégrité ;
• SSH pour l'authentification et l'exécution à distance de commandes ;
• Bash pour l'exécution de scripts de livraison.

Un prototype fonctionnel se trouve sur Github, ainsi que plus d'informations et de documentation.

Contrairement à un simple Git push/checkout, Git-deliver :

• rend la livraison « atomique » ;
• structure la livraison en étapes et gère les erreurs tout en maintenant la disponibilité du logiciel ;
• archive les livraisons et automatise les retours en arrière (« rollback ») ;
• garde un journal des opérations ;
• fournit une façon simple de savoir quelle version est livrée sur quel serveur, de valider l'intégrité des livraisons, et de savoir quand et par qui une version a été livrée ;
• prévoit d'intégrer des recettes de livraison préfabriquées pour les environnements les plus courants.

Nix est un gestionnaire de paquets fonctionnel dont la version 2.0 est sortie récemment. Parmi les nouveautés, on peut noter qu’une commande nix a été introduite pour uniformiser les différentes sous‐commandes (nix-build, nix-env, etc.) et avoir de meilleures options par défaut (pour la recherche de paquets notamment). Une bonne partie du reste du travail concerne des couches moins visibles mais néanmoins importantes : prise en charge de HTTP/2, amélioration de sécurité, etc.

Nix peut être utilisé sur n’importe quelle distribution GNU/Linux en complément du gestionnaire de paquets habituel. Il existe également une distribution GNU/Linux articulée autour de Nix : NixOS. La version 18.03 de NixOS, prévue pour sortir très prochainement, inclura Nix 2.0.

Mise à jour : Nix 18.03 est sorti.

La semaine passée, à un jour d’intervalle, deux petites nouvelles concernant l’actuel chouchou des gestionnaires de version, à savoir Git, sont passées un peu inaperçues. Ce dernier vient de sortir, le 21 octobre, en version 1.8.0, et Gitlab, application Web d’autogestion de projets sous Git, passe, lui, en version 3.0 depuis le 22 octobre.

Les nouveautés de ces deux logiciels sont un peu plus détaillées dans la seconde partie de la dépêche.

Gitlab achète Gitorious. Les utilisateurs ont jusqu'à fin mai 2015 pour importer leur projet sur Gitlab (en un clic).

Selon les mots de Rolf Bjaanes, le CEO de Gitorious, dans le billet officiel, Gitorious.org n'était plus viable économiquement : «À Gitorious nous voyions de plus en plus d'organisations adopter Gitlab. À cause d'une baisse des revenus des comptes payants, il n'était plus tenable de maintenir l'instance gratuite Gitorious.org. Gitlab résolvait le même problème que nous, mais mieux.» ("At Gitorious we saw more and more organizations adopting GitLab. Due to decreased income from on-premises customers, running the free Gitorious.org was no longer sustainable. GitLab was solving the same problem that we were, but was solving it better.”

Rien n'est dit sur ce qui va advenir du code de Gitorious.

C'est un logiciel totalement libre et sous licence AGPLv3 qui meurt, remplacé par un autre sous licence MIT avec une édition communautaire et une privée.

Des pronostics pour quand Gitlab rachètera Github ?

« If there’s something strange
In your history
Who you gonna call?
GitBuster! »

Qui ne s’est jamais retrouvé au milieu d’un conflit de merge cataclysmique, à ne plus savoir distinguer ciel et terre ? À moins d’être un utilisateur expérimenté, ce genre de situation a de quoi rebuter et faire passer à côté de toute la richesse de Git.

Gitbuster, développé par Julien Miotte est un frontal graphique à des outils comme « git rebase », « git cherry-pick » et « git filter-branch ». Le projet est parti à l’origine d’un besoin très personnel de l’auteur de faciliter l’utilisation de « git filter-branch », un outil très performant de réécriture des informations de commit. Le développement, guidé par les demandes de fonctionnalités, notamment de chefs de projet, s’est orienté vers d’autres fonctionnalités de Git, comme le rebase et le cherry-pick.

Gitbuster offre les fonctionnalités suivantes :

• cherry-pick par glisser‐déposer d’une branche sur une autre ;
• résolution interactive des conflits de merge ;
• création d’une branche à partir d’un commit (git checkout 1234567 -b new_branch) ;
• modification des métadonnées de n’importe quel commit de l’historique ;
• cherry-pick à partir d’un dépôt distant (qu’il soit sur le Web ou dans un autre répertoire) ;
• modification automatique des dates de commit d’une plage horaire vers une autre.

Apache Subversion 1.7 est sorti le 11 octobre. Attendue de longue date, cette version majeure apporte de nombreux changements dans lesquels on ressent l’influence de la popularité croissante des gestionnaires de versions décentralisés.

Cette version 1.7 est compatible avec les versions précédentes, côtés client et serveur, même si les nouvelles fonctionnalités (détaillées dans la seconde partie de la dépêche) ne seront pas toutes disponibles.

Mercurial, un puissant logiciel de gestion de versions écrit en Python, sort en version 2.1 après 3 mois de développement.
Pour rappel, Mercurial est un logiciel de gestion de version décentralisé, à savoir qu'il permet de travailler en équipe sans avoir besoin d'un serveur centralisé. Tous les développeurs pouvant se synchroniser entre eux, via deux méthodes :

• pull : réception des modifications d'un dépôt distant.
• push : envoi des modifications vers un dépôt distant.

Cette souplesse permet de hiérarchiser le développement d'un projet de mille et une façons. Cette souplesse possède un revers, quand l'on doit se synchroniser avec un dépôt distant on a souvent des conflits. Pour les résoudre, les développeurs font appel à deux méthodes :

• merge : fusion des modifications de deux branches en une seule, les conflits sont résolus par divers outils manuels ou automatiques.
• rebase, mq, histedit : modification de l'historique des modifications afin de le linéariser ou de le simplifier.

Dans le second cas, modifier son historique peut s'avérer bien plus désastreux que le problème initial ou l'on avait qu'un simple conflit. Git, le principal concurrent de Mercurial qui possède des fonctionnalités et des performances sensiblement identiques, est particulièrement sensible à des erreurs de rebase, car cette fonctionnalité est activé par défaut.

Pour éviter les erreurs de modifications d'historiques, Mercurial 2.1 introduit une nouvelle fonctionnalité : les phases.

Le projet que je vais développer ici est une boîte à outils pour Gitlab CI publié sous licence GNU GPL v3, dont la fonction principale est d’exécuter les tâches GitLab manuellement, individuellement et simplement sur votre station de développement. J’ai commencé son développement début 2017 dans le cadre de ma mission chez ERCOM et, à ce jour, il a atteint un bon stade de maturité. Il est désormais utilisé par deux équipes sur au moins une dizaine de projets.
GitLab (Community Edition) est un logiciel libre, sous licence MIT. Il s’agit d’une forge logicielle équivalente à GitHub et la partie mentionnée, GitLab CI, est une fonctionnalité d’intégration continue équivalente au service Travis CI

gws est un outil KISS (script bash, compatible zsh) pour gérer de manière simple un espace de travail composé de plusieurs dépôts git. Ça ne vous parle pas et vous semble être un pitch commercial ? Laissez-moi l'aborder autrement ; si vous vous reconnaissez dans quelques-unes de ces questions, cet outil pourrait vous être utile :

• Vous avez un dossier ~/dev/, ~/code/ ou ~/workspace/ dans votre répertoire personnel ?
• Vous y avez cloné dedans plein de dépôts git ?
• Vous ne savez jamais quels dépôts, branches, commits n'ont pas été synchronisés ?
• Vous en avez marre d'avoir à faire 17 git pull manuellement le lundi matin au boulot ?
• Vous déprimez en arrivant dans le train de voir que vous n'avez pas récupéré votre dernier projet sur votre ordinateur portable ?

La version 2.20.0 de Git, logiciel de gestion de versions décentralisé, vient tout juste d’être étiquetée par Junio Hamano, le mainteneur. Elle contient comme toujours un nombre important d’améliorations, même si elles ne sont pas forcément visibles par la plupart des utilisateurs (certaines nouveautés sont détaillées en seconde partie de la dépêche).

Pour être tenu au courant de l’actualité Git, il y a Git Rev News, une lettre d’actus mensuelle qui contient pas mal d’infos en tout genre liées à Git (Git Rev News est éditée depuis presque quatre ans par un petit groupe de développeurs et de fans dont je fais partie).

Il y a aussi prochainement la conférence Git Merge à Bruxelles le 1^er février prochain, juste avant le FOSDEM (2 et 3 février). Oui, c’est au même endroit, appelé The EGG Brussels, que la Git Merge 2017 qui avait aussi lieu juste avant le FOSDEM. Comme d’habitude, le jour précédant la Git Merge proprement dite (donc le 31 janvier), des workshops sont proposés et, en parallèle, il y a un Git Contributor Summit auquel tous les développeurs de Git ou d’un logiciel lié à l’écosystème de Git sont invités.

BitKeeper, logiciel de gestion de version vient discrètement de passer en Open Source, sous licence Apache 2.0. Soit plus de dix ans après l'avènement de Git dont il est indirectement à l'origine. Que de temps pour trouver le bon chemin !

Enfin diront certains, trop tard diront d'autres. Le changement s'est fait relativement discrètement via l'annonce assez laconique de la version Bk-7.2ce sur leur forum :

I might as well mention bk-7.2ce which is the first open-source release.

Si vous vous demandez si cela vaut le coup de laisser tomber votre SCM préféré, ils ont en place une page spécialement pour vous. Ironie de l'histoire, sur leur page de téléchargement, ils proposent de récupérer les sources de BitKeeper via Git !

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.

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.

Heptapod est une divergence (fork) amicale de GitLab CE qui prend en charge le DVCS Mercurial. Le projet a deux ans et est actuellement disponible sous forme de sources et d’image Docker à installer.

Veracity est un nouveau gestionnaire de versions décentralisé (DVCS), sous licence Apache. Il est développé en C par la société SourceGear, avec la possibilité d'embarquer des greffons en javascript.

Comparé à git ou mercurial, il essaye d'intégrer une expérience de développement plus large :

• interface web complète (vous pouvez voir à quoi elle ressemble en consultant le dépôt public de Veracity) ;
• flux d'activité ;
• suivi des bugs distribué ;
• graphe burndown.

Il est possible de l'installer sous GNU/Linux, Mac et Windows. Des paquets pour Ubuntu et un guide sont également disponibles pour vous aider à démarrer.

Trac est un outil de gestion de « tickets » (rapports de bugs) développé en Python. Il était beaucoup utilisé à l’époque de SVN mais a aujourd’hui laissé la place, dans beaucoup de cas, à des outils plus gros comme GitHub (pas libre) ou GitLab. Il continue toutefois son développement et est toujours utilisé par certains projets, en particulier parce qu’il est assez simple à personnaliser à l’aide de plug-ins et facile à déployer.

Les versions 1.5.x sont les versions de développement avant la publication d'une version stable 1.6.x. La branche 1.4 continue également des corrections de bugs. Le rythme de développement n'est pas très rapide puisque la version 1.5.3 date de mai 2021, et il y a finalement assez peu de changements d'une version à la suivante.

Gitblit est un outil de gestion de dépôt Git, à l’instar de Gitosis ou Gitolite. L’idée est de permettre de partager ses dépôts, gérer des droits d'accès, fournir des sauvegardes… tout en restant dans les murs de l’entreprise si nécessaire.

Pour les entreprises, justement, qui n’ont pas toujours de compétences Rails ou de culture des clefs SSH, Gitblit possède certains atouts. Au niveau administration, avec une application légère en Java, autonome ou hébergeable dans un Tomcat ou dans le Cloud.
Au niveau de la gestion des utilisateurs, Gitblit offre, au choix, des solutions généralement appréciées des entreprises : LDAP ou Active directory avec gestion des habilitations basée sur les groupes, Windows, PAM, Conteneur type Tomcat ou personnalisé. La gestion par clefs SSH sera apportée par la version 1.5.

Associé aux autres fonctionnalités plus courantes, Gitblit offre la possibilité de mettre en place un Github-like dans son entreprise.

Gérer du code dans plusieurs dépôts différents est toujours un peu compliqué. Chez tanker.io nous avons une petite équipe de développeurs, et chacun des membres peut être amené à coder dans plusieurs langages (C++, Go et JavaScript, principalement). Comme une grande partie du code est encore propriétaire, nous utilisons une instance GitLab hébergée dans nos locaux.

Il existe plusieurs façons de gérer la synchronisation entre dépôts : la manière qui nous convient le mieux est d’avoir la même branche (ou le même tag) sur les dépôts concernés. Ceci nous a amené à développer notre propre outil, tsrc, qui est désormais disponible sur GitHub, sous licence BSD.

Pourquoi GitHub et pas GitLab ? Simplement parce que GitHub, bien que propriétaire, assure une meilleure visibilité au projet.

Je vous présente aujour’hui un de mes projets personnels : Updates-warner.

C’est un logiciel libre (GPL v3), écrit en C, d’environ 9 250 lignes de code (environ trois mois de dev’, sur mon temps libre). Ce projet est né suite à un besoin que j’ai de suivre certains projets pour des questions de sécurité dans mon boulot. La première esquisse était un script shell que je lançais manuellement tous les jours. Par flemme, j’ai donc créé ce logiciel qui est beaucoup plus beau, pratique et multi‐tâches ! Et j’ai décidé de le partager, j’espère que vous le trouverez tout aussi pratique que moi !