J’ai migré sur GitHub un certain nombre de projets dont je mène le développement.
L’URL est simple : https://github.com/Amaury
Voici une rapide présentation des projets en question.
Temma
Le framework que j’ai développé au sein de mon entreprise. C’est un framework MVC écrit en PHP, qui accélère les développements par son fonctionnement très facile à appréhender.
Toute la documentation est disponible sur http://www.temma.net
FineFS
C’est le système de fichier redondé utilisé là aussi dans mon entreprise. Son principe est de permettre l’accès à des fichiers depuis plusieurs machines d’un même cluster, avec un fonctionnement à la fois synchrone et asynchrone. Il est codé en PHP.
En attendant que toute la documentation soit migrée sur GitHub, elle est toujours visible sur GoogleCode : http://finefs.googlecode.com
FineBase
Il s’agit d’une bibliothèque de fonctionnalités basiques, écrite en PHP. C’est la brique de base sur laquelle Temma et FineFS sont fondés. Les fonctionnalités offertes sont :
- Système de lock, pour empêcher plusieurs exécutions concurrentes d’un même programme ou plusieurs accès simultanés à une même ressource.
- Système de log, pour écrire des messages qui vont être publiés (dans un fichier, sur la sortie d’erreur, via syslog, ou transmis à des handlers) en fonction de leur criticité et des seuils de criticité minimale définis pour chaque couche logicielle. Cela permet par exemple d’avoir un programme pour lequel on verra les erreurs des couches les plus basses, et tous les messages de débuggage pour les couches les plus hautes.
- Un objet de gestion unifiée des sessions, un autre pour la base de données, un autre pour l’accès au cache (utilisant Memcache).
- Un wrapper sur HTML Tidy pour nettoyer du code HTML généré par WYSIWYG.
- Une file de messages stockée en base de données.
- Une extension au SoapClient de PHP, pour supporter l’authentification WSSecurity.
- Un chronomètre de temps d’exécution.
- Un objet de registre, un objet d’écriture ANSI sur la ligne de commande, quelques objets d’exception, …
HeaderBrowser
C’est un outil de génération de documentation à partir de code source en C ou en C++. Dans l’idée, il est assez similaire à JavaDoc ou PHPdoc, se basant sur des commentaires contenant des marquages spéciaux. Par contre, la documentation générées est affichée d’une manière qui facilite grandement la navigation ; vous pouvez en trouver un exemple pour la bibliothèque Ylib (voir plus bas).
Écrit en C++, cet outil est maintenant un peu ancien.
Plus d’information sur le site http://www.headerbrowser.org
Ylib
Ce projet propose une bibliothèque de fonctions, écrite en C. Il y a pas mal de choses à l’intérieur :
- Calcul de CRC, encodage/décodage en Base64 et quoted-printable.
- Quelques helpers sur la gestion de la mémoire (malloc/free).
- Gestion du lock et du log.
- Chronomètre de temps d’exécution.
- Décodage d’URL.
- Chaîne de caractère bufferisée, vecteurs bufferisés.
- Gestion simplifiée de scripts CGI.
- Parseurs XML, SAX et DOM, et interprétation XPath.
- Wrapper de connexion réseau, helper de création de démon.
- …
La documentation, générée avec HeaderBrowser : http://ylib.amaury.net/hbresult-html/
Carta Genius
Là il s’agit d’un logiciel servant à créer des documents PDF de qualité professionnelle. Je l’avais créé au début pour faire des planches de cartes de jeu, que je faisais imprimer par des imprimeurs numériques professionnels. Cela demandait un certain nombre de fonctionnalités particulières : réutilisation d’images, transparence, traits de coupe (pour que l’imprimeur sache où couper, sans que les traits n’apparaissent sur les cartes), fond perdu, imposition (faire correspondre le recto et le verso), etc.
Par la suite, j’y ai ajouté pas mal de possibilités, qui permettent de l’utiliser pour générer tout type de PDF. J’y ai notamment ajouté un interpréteur, qui permet de faire des écritures assez poussées.
En conclusion
Je ne suis pas encore opérationnel à 100% avec Git. J’ai tellement l’habitude de Subversion que plusieurs choses me semblent inutilement complexes avec Git. Mais il faut reconnaître que c’est très pratique pour faciliter les contributions sur un projet open-source.
N’hésitez pas à cloner les projets et à faire des « pull requests » pour me proposer vos améliorations. J’y apporterai toute l’attention nécessaire.
Merci pour ce blog, je le lis regulierement via son flux RSS.
Je ne m’attarderais pas sur le fond de vos projets mais sur la forme. Quand je compte utiliser un code source je regarde 2 choses :
– L’historique des commits pour voir si c’est propre ou pas
– Et le plus important, s’il y a des tests automatises
Dommage, ici il n’y a ni l’un ni l’autre.
Les tests, pas besoin d’argumenter, tout le monde sait que c’est bien ; je dirais que c’est meme indispensable 😉
Pour l’historique des commits on pense a tort que ce n’est pas tres important, pourtant cela retrace le cheminement intellectuel qui a permis d’arriver a la solution finale. En pratique c’est une mine d’information incroyable sur un projet.
Git permet d’importer un repo depuis svn (j’imagine que c’est ce que vous utilisiez avant) en gardant toute l’historique. On peut meme bidouiller tout ca grace a svndumpfilter et svndumptool. Je pense que ca vaut vraiment le coup d’y passer du temps.
Encore quelques temps et ton opinion sur svn/git pourrait bien s’inverser.
@tkrotoff : (tutoyons-nous) Tu as complètement raison.
Concernant l’historique, j’ai une bonne explication. Les projets que je viens d’importer ont 2 origines : Soit ce sont des projets assez anciens, qui n’étaient pas versionnés (Ylib, Carta Genius, HeaderBrowser), soit des projets qui sont nés dans mon entreprise (FineBase, Temma, FineFS) et dont l’historique SVN peut contenir des choses que je ne veux pas forcément rendre publiques, pour des raisons de confidentialité.
Donc je suis désolé, mais ça va rester comme ça.
Au sujet des tests, il y a là 3 cas de figure : Les projets anciens écrits en C/C++ n’ont pas de test unitaire. Et il y a peu de chance que je prenne le temps d’en écrire un jour.
Pour FineBase, il s’agit simplement d’un oubli, je pensais les avoir ajoutés.
Pour Temma et FineFS, c’est plus délicat. Ils sont difficiles à tester, donc les tests existants sont plus qu’incomplets. En plus, ils avaient été écrits avec SimpleTest ; nous avions commencé une migration vers PHPUnit, qui a été terminée pour FineBase mais pas encore pour Temma ni FineFS. J’attends donc d’améliorer un peu tout ça avant de le publier.
@desfrenes : Je n’ai pas dit que Git est forcément complexe en soi. C’est juste que pour une utilisation classique en entreprise, je pense que le modèle centralisé est plus simple à manipuler que le modèle décentralisé.
Oui, à cela on me rétorque toujours que Git permet de faire des trucs impossibles avec SVN. Je suis d’accord, c’est le principe même. Mais quels trucs impossibles ? La plupart du temps, le premier exemple qui est donné, c’est le gars qui code dans le train, et qui veut quand même pouvoir commiter.
Mouais, c’est quand même un cas d’utilisation hyper-rare. Mes développeurs ne codent pas dans le train.
Dans le cas d’utilisation le plus basique, on se contente de faire des commits pour publier nos modifications, alors qu’avec Git on devrait commiter puis faire des pushs. Ça a l’air con, mais être obligé de gérer 2 étapes au lieu d’une, ça ne peut avoir d’intérêt que si on a besoin des autres fonctionnalités.
Donc j’en reviens à ce que je disais : Pour les projets open-source, le décentralisé est purement génial. En entreprise, et à plus forte raison avec une équipe de taille raisonnable, le centralisé est plus simple et plus rapide.
Concernant l’usage de Git, l’intérêt de la possibilité de travailler offline dépend du type de poste. Pour moi qui passe pas mal de temps dans des trains, des hôtels ou chez des clients dont le wifi marche plus ou moins c’est super utile.
Au niveau des choses très pratiques que Subversion ne sait pas faire je mettrais en avant :
– les stashes dont tu as sans doute rêvé depuis des années (cf. http://progit.org/book/ch6-3.html)
– modification d’un commit (amend et reset –soft HEAD^1 qui sauve souvent la vie aux débutants … et pas qu’à eux d’ailleurs)
– réécriture de l’historique (rebase intéractif)
– cherry picking
– la souplesse et la rapidité de gestion des branches
– rerere (cf. http://progit.org/2010/03/08/rerere.html)
En revanche, il est clair que c’est (un peu) plus complexe mais le vrai problème pour quelqu’un qui vient de Subversion ce sont les habitudes. J’ai remarqué que les gens n’ayant jamais utilisé d’outil de versionnement s’en sortent généralement mieux que ceux qui ont une expérience de Subversion.
@Jean-Marc : Oui, tu as raison. La force de l’habitude… Mais surtout, la courbe d’apprentissage me semble importante, pour un gain immédiat pas évident. Si je regarde comment on travaille dans mon entreprise, il y a 95% du boulot qui est fait avec les commandes Subversion basiques (diff, commit, update), 3% qui concerne les conflits (diff/resolved/commit), et moins de 2% qui concerne des cas un peu « tricky » (équivalent des stashes ou du cherry picking, mais complètement à la main). Je le sais parce qu’on avait fait l’effort d’analyser notre utilisation de Subversion il y a quelques temps.
Alors bon, même si je me donne le temps de monter tranquillement en compétence sur Git (et de changer d’avis par la suite), je sais aussi que dans la situation actuelle − projets et équipe de tailles raisonnables, pas de commit dans le train − il est plus intéressant de rester sur SVN que de vouloir former tout le monde à Git.
Mais en tout cas, merci pour les liens ! 😉
Et je le répète, pour les projets open-source, y’a pas mieux que l’approche décentralisée. Ensuite, entre Git et Mercurial (par exemple), il faut avouer que GitHub.com est devenu un incontournable et fait vite pencher la balance en faveur de Git.
@Amaury : j’utilise git au travail alors que mes collègues utilisent subversion, y a pas photo :
– ayant un réseau capricieux, je peux continuer à travailler sans problème ;
– je ne suis pas obligé que tout fonctionne pour commiter du coup mes commit sont plus petits ;
– je suis quelque peut maniaque avec mon code, là je peux aussi l’être avec les commit (modification du message de commit et du contenu des commits), quand j’envoie du SVN c’est propre et atomique (un commit = une fonctionnalité ou correction) ;
– manipulation des branches instantanée ;
– les commit temporaires (git stash) permettent de mettre de côté une tâches lorsque mon chef de projet veux que je corrige quelque chose dans l’urgence.
J’ai découvert la puissance de git le jour où j’ai arrêter de l’utiliser comme un gestionnaire de version pour l’utiliser comme un gestionnaire de commit.
@Amaury : Je pense que les 2% de choses « tricky » évolueront avec Git car cela sera nettement plus simple à faire.
Concernant les stashes c’est loin d’être anecdotique. Cela répond même à un besoin hyper courant que ne peut gérer que manuellement, et souvent mal, avec Subversion. L’exemple typique c’est le correctif urgent à effectuer alors que tu es en train de coder une fonctionnalités qui va prendre du temps à être au point. Tu mets tout de côté de manière propre, tu corriges, tu commites, tu publies et tu reviens exactement là où tu étais sans risque de perte ou de commit intempestif.
Un truc pas impossible à faire avec svn: des branches. C’est pas impossible, c’est pire: cauchemardesque, au point qu’il vaudrait mieux que ça le soit (impossible). Après quelques temps à souffrir j’ai décidé qu’on allait switcher fissa, pas pour coder dans le train… Juste pour pouvoir travailler efficacement avec des branches avec toutes les facilités que ça induit.
@Sanpi : Merci pour ce retour d’expérience. C’est intéressant.
Juste pour me faire l’avocat du Diable, je dirais quand même :
– Bah faudrait commencer par avoir un réseau stable 😉
– Modifier les messages de commit, c’est aussi possible avec SVN. Modifier le contenu d’un commit, ça m’horrifie. On re-committe et/ou on crée une branche. Mais modifier a posteriori le contenu d’un commit, je trouve ça bien goret.
– La création d’une branche, avec Subversion, ça correspond simplement à la création d’un répertoire. C’est pas la mort non plus.
@Jean-Marc : Oui, ton exemple décrit très bien les choses. Mais chez nous, ce genre de chose arrive très rarement. Sûrement parce que notre organisation fait que, naturellement, on se retrouve rarement à faire des petits trucs à l’arrache qui overlap un truc en cours de développement.
Je ne dis pas que le besoin n’existe pas, je dis juste que je n’y suis pas assez confronté pour que ça devienne la killer-feature qui me fera jeter SVN en faveur Git.
@Desfresnes : Bah non, je le répète, les branches avec Subversion, c’est juste une copie de répertoire. Comme les tags. Ce qui est éventuellement pénible, c’est le merge lorsqu’il y a beaucoup de différences entre les branches mergées. Mais là, je ne vois pas trop de méthode miracle.
La seule chose que je reproche aux tags et aux branches de Subversion, c’est que c’est un peu galère pour savoir d’où la branche a été créée. Pour retrouver cette information, c’est au final plus simple de le noter dans un wiki plutôt que d’utiliser des outils ; ça c’est dommage.
@Amaury : Je pense que ta perception de la gravité de modifier un commit est biaisée par ton habitude de Subversion. Avec Git, il faut bien distinguer deux historiques : le local et le distant qui lui est partagé.
A moins d’être un génie qui code du premier coup les choses dans un ordre cohérent et clair, réécrire l’historique local est une bonne pratique avec Git. Cela permet d’effacer les tâtonnements et les petits erreurs de développement. Le but n’est pas de couvrir ses erreurs mais de fournir un historique propre à ses collègues.
En revanche, modifier un commit déjà poussé sur le dépôt distant ne doit être fait que quand la situation l’exige et avec de multiples précautions.
@Jean-Marc : Oui, tu as complètement raison. J’avais raisonné en pensant au repository master, pas aux modifications locales.
Ton explication est très claire et didactique 🙂
> des projets qui sont nés dans mon entreprise (FineBase, Temma, FineFS) et
> dont l’historique SVN peut contenir des choses que je ne veux pas forcément
> rendre publiques, pour des raisons de confidentialité.
Ca tombe bien, c’est pour ca que j’ai indiqué :
« On peut meme bidouiller tout ca grace a svndumpfilter et svndumptool. »
Tu peux ecrire tes propres scripts pour modifier en profondeur l’historique d’un projet.
Et une fois le repo svn importe dans git, tu peux aussi retravailler tout ca avant de le rendre publique.
> J’attends donc d’améliorer un peu tout ça avant de le publier.
Ce n’est pas parceque ce n’est pas fini qu’il ne faut pas le publier. Au contraire c’est tout l’interet du versionning ! Perso je versionne des le 1er jour d’un projet (le fichier README par exemple).
@tkrotoff : Oui, tu as raison d’un point de vue théorique. En pratique, je n’ai pas prévu de passer des heures carrées sur cette migration vers GitHub. C’est pas bien, ça peut nuire à la propagation des projets… mais d’un autre côté, ça ne peut pas être pire qu’avant ! 😀
J’ai publié le code ; je vais essayer de propager sur les repository Git toutes les évolutions qu’on va faire sur notre SVN interne ; j’essaye de documenter un minimum les choses. Alors bon, je considère un peu que le versionning « public » a commencé hier. 😉
Bon, au final c’est un peu dommage que le sujet ait uniquement dérivé sur « SVN vs Git ». J’aurais préféré qu’on discute un peu des projets présentés… 😉
« J’aurais préféré qu’on discute un peu des projets présentés »
Comment FineFS se différencie de MogileFS (par ex) ? http://danga.com/mogilefs/
@desfresnes : Ah, ça c’est une question que j’aime ! 🙂
On peut comparer FineFS avec tout plein de systèmes. Ceux qui s’en rapprochent le plus sont MogileFS et Tahoe.
Le design est fondamentalement différent. L’un n’est pas meilleur que l’autre, ils n’ont simplement pas les mêmes buts. Dans le cas de FineFS, le but était de répliquer (et non répartir) les données sur tous les nœuds du cluster, ce qui conduit à éliminer la latence réseau la plupart du temps. Mais ça implique évidemment d’avoir un dataset qui tienne sur les disque locaux.
Le cas d’utilisation typique, c’est les médias qui doivent être servis par des serveurs frontaux. Avec FineFS, tous les médias sont présents sur tous les frontaux, ce qui optimise l’utilisation des disques (on a maintenant des frontaux avec des disques à ne plus savoir qu’en faire) et réduit les temps d’accès (les données sont accédées en local).
Sinon, MogileFS a une architecture centralisée, alors que FineFS est complètement décentralisé.
D’un point de vue langage, MogileFS est écrit en Perl, Tahoe en Python. Il n’y avait aucun équivalent de près ou de loin en PHP, avant FineFS.
Tu peux lire les commentaires qui ont suivi l’annonce sur LinuxFR. J’avais pris le temps d’expliquer les choix de design.
Bonjour,
J’ai trouvé ce fil de discussion très enrichissant. Je souhaite donc vous soumettre un lien intéressant en rapport avec les propos sur Git :
http://fr.whygitisbetterthanx.com/
N’étant pas expert en la matière j’espère qu’il ne s’agit pas simplement d’une propagande.
J’aurais souhaité avoir votre avis sur le sujet, en espérant que ce soit bien l’endroit pour le faire (conclusion du billet traitant de Git), sinon je vous prie de bien vouloir m’excuser.
@Kwadz : Merci pour le lien. Je le connaissais. La plupart des choses qui y sont écrites sont vraies, mais il y a quand même un côté énervant que j’avais déjà remarqué dans l’introduction de Pro Git, avec l’utilisation d’assertions en partie vraies.
Gestion rapide des branches : Git est rapide, certes. Mais ça fait l’objet d’un autre point mis en avant. Pour le reste, la manière dont c’est expliqué fait croire que les autres systèmes ne gèrent pas du tout les branches. Alors que, je le répète, avec SVN la création de branche revient simplement à copier un répertoire (svn cp source destination).
Tout en local : Là encore, je vais me répéter. Mais pour moi, commiter dans le train est un cas hyper-exceptionnel, pas la norme. Je sais que ce n’est pas le cas de tout le monde, mais quand même. De là à le lister systématiquement comme avantage numéro 1, ça me fait rire. En plus, avec SVN, les comparaisons (diff) se font aussi complètement en local, sans connexion au serveur, alors que ce site et Pro Git semblent dire le contraire (sans l’affirmer réellement, c’est le principe de la propagande).
Git est léger : Il commence par dire que les fichiers copiés en local sont à peine plus gros qu’avec SVN. Puis il prend l’exemple (ultra-spécifique) du projet Django pour dire qu’il est parfois plus performant. Moui, c’est sûr que c’est hyper-important…
Distribué : Pour moi, le modèle centralisé et le modèle distribué ont chacun des avantages et des inconvénients. Dire que l’un est clairement est échec et que l’autre est la seule solution d’avenir, c’est complètement débile.
Apprentissage facile : Euh… sans rire ?
Un des aspects qui est fréquemment mis en avant, c’est que Git permet d’avoir des dépôts locaux, avec des branches et des commits purement locaux. C’est censé être super-génial parce qu’ainsi on travail dans son coin sans dépendre des autres, et qu’on ne pousse sur le master que quand on a des releases stables. Et au passage, ce qui est génial, c’est que si le master tombe en panne, il suffit de reprendre la copie locale de quelqu’un pour le reconstruire.
Sauf qu’en pratique, il ne faut pas oublier que le besoin peut être différent. Personnellement, l’aspect centralisé de SVN me permet de commencer un développement sur une machine, de le commiter, puis de le récupérer et de le poursuivre sur une autre machine. Oui, c’est possible avec Git, mais ça ne correspond pas vraiment à la philosophie. Et pourtant, c’est un besoin très fréquent chez moi, contrairement aux commits dans le train…
Concernant la perte de données, je suis totalement convaincu qu’il est plus facile de s’assurer de la sauvegarde régulière d’un serveur centralisé, plutôt que de compter sur les copies locales des uns et des autres…
Bref, tout ça pour dire – encore une fois – que je suis convaincu de la qualité de Git et de l’approche décentralisée. Mais je ne supporte pas qu’on soit obligé de dire que les autres solutions sont de la merde. Chacun peut coexister avec ses propres qualités et faiblesses. Et pour moi, le centralisé a encore beaucoup d’avantages dans certaines conditions pour vouloir l’enterrer aussi vite.
J’ai travaillé sur SVN il y a quelques temps, mais le passage à GIT dans mon entreprise a fini de me convaincre !
Pour moi les avantages :
– Le local ! Je fais tout en local et ne « push » que ce qui est terminé et propre. J’ai donc mon historique, mes commits, mes projets, mes expérimentations, …
– Les branches. Elles sont d’une simplicité enfantine … Chez nous tout est branche, le master étant la version en prod. La moindre fonctionnalité est d’abord mise sur une branche, testée, puis rapatriée sur le master. Les Merges sur GIT sont ultra-performants, jamais de loupés. La encore, branches partagées ou branches locales, tout est possible.
– Les dépôts « bare » sont des dépôts, sur un serveur distant, qui stockent tous les commits. Pas de version de travail exploitable ici, cela permet juste de centraliser les projets pour de futurs clonage et faire les backups. Possibilité d’y brancher des « hooks » pour automatiser des taches (mais je crois qu’SVN le permet aussi) : vérification des charsets, génération de doc, liaison au bugtracker, …
– Le méthode de stockage des dépots (à vérifier). Git stocke les modifications faites au fichiers, contrairement à SVN qui stocke toutes les versions. Sur de gros projets, la différence peut vite se faire sentir en terme d’espace de stockage.
– Autre point et non des moindres : sur GIT il n’y a qu’un dossier .git à la racine des projets. Tout est dedans. Fini les .svn dans chaque dossier ! On peut également chambouler et déplacer n’importe comment les dossiers sans risquer de frustrer le monsieur.
Bref, depuis que je l’utilise quotidiennement, j’en suis pleinement comblé ! Et pour rien au monde je ne retournerai sur SVN, bien qu’il m’ait rendu de bons et loyaux services 😉
> des projets qui sont nés dans mon entreprise (FineBase, Temma, FineFS) et
> dont l’historique SVN peut contenir des choses que je ne veux pas forcément
> rendre publiques, pour des raisons de confidentialité.
Je ne savais pas que ces historiques pouvais contenir des choses confidentielles…
J’utilise souvent Git et je le trouve très bien.
Et j’utilise également en parallèle Bazaar.
@Manu : Oui, les historiques SVN peuvent contenir des informations sur les projets de l’entreprise, son business, ses collaborateurs, ses clients, etc.