Ceci étant dit, rien n'est encore fait, mais il semblerait que nous en prenions clairement le chemin.
Pour une part, il est clair que CVS peut être considéré à juste titre comme un gestionnaire de version pour le peu archaïque. Et il ne faut pas s'en étonner, ce système a tout de même plus de 20 ans !
Pour revenir à nos moutons, nous étions beaucoup à nous demander quand drupal.org se déciderait à basculer le dépôt des modules contribution (et du core) sur quelque chose de plus moderne, comme au hasard, subversion. Manque de bol, la grande mode des gestionnaires de version distribués est passée par là, et subversion nous est passé sous le nez au profit de GIT.
Alors qu'est-ce qu'un
La gestion décentralisée de version permet donc à chacun, y compris de petites équipes, de travailler sur les sources d'un projet tout en laissant à d'autre le choix d'intégrer ou pas les modifications au sein du projet central. C'est en quelque sorte la notion de fork généralisé. Ce concept est très intéressant pour permettre à toute une communauté de s'exprimer sur des projets d'envergure comme le noyau Linux, ou dans une moindre mesure, Drupal Core. C'est d'ailleurs Torvald, après une saga autour du gestionnaire de version propriétaire BitKeeper, qui a écrit les premières moutures de GIT. Mais
Entendons nous bien, je n'ai absolument rien contre ce type de gestionnaire, et encore moins contre GIT que j'envisage d'adopter pour mes propres projets. Mais autant je peux comprendre ce choix dans le cas du core de Drupal, autant pour la myriade de modules contribs, maintenus à grand peine par de petits développeurs dans leur coin (dont je fais parti) qui n'ont pas que cela à foutre de jongler d'un gestionnaire à l'autre. Et si l'on met ceci en perspective du fait que l'adoption massive de Subversion en entreprise est enfin concrétisée, GIT un choix que je trouve un peu... lourd.
D'autant plus lourd que ce produit, comme son concept de base, est très jeune. Cela veut dire apprendre un nouveau mode de fonctionnement pour ceux qui ont déjà eu du mal à passer à SVN, mais cela implique aussi une maturité plus faible sur des plate-formes comme
Je pense que tu n'a pas encore envisagé ce que permet un gestionnaire de version décentralisé. Par exemple je m'en sers pour travailler seul. J'initialise le dépôt je fait mon premier commit et comme ça je suis soulagé des évantuelles érreurs de manip' sur mes sources.
De plus il y a git-svn qui permet d'utiliser git avec un serveur subversion.
git me semble un choix réellement très flexible, même si je ne connais que très peut bazaar et mercurial (ni svk d'ailleurs).
Ah bé j'ai pas besoin d'être convaincu hein :) Moi le risque que j'essaye de souligner c'est qu'il y a fallu bien 5 ans avant que subversion devienne un standard en entreprise, et si GIT (ou un autre décentralisé) le devient, ce sera sans aucun doute dans le même temps. Ce que je crains donc c'est que cela va être un outil de plus à utiliser pour les devs de modules, à apprendre aussi, et surtout à comprendre.
Maintenant pour les avantages de GIT que tu cites, je fais strictement la même chose avec subversion. En effet, rien ne m'empêche de créer un dépôt local et de commiter dedans. Pour moi le véritable intérêt des décentralisés arrive lorsque l'on travaille à plusieurs, et surtout à plusieurs équipes. En plus, il n'y a pas grand chose de sécurisant à avoir un dépôt local mise à part pour revenir en arrière sur des modifications, car si tu as ton disque qui crash, tu apprécieras que tes sources soient sur une machine séparée.
Une des idées de git, c'est d'avoir plusieurs branches rien que pour soi, pour travailler sur différentes features. Ça n'a donc pas que de l'intérêt en multi.
Puis il y'a les performances aussi. Au bout de quelques checkout/clones, tu vas vite aller danser sur la tombe de svn !
Par contre je connais pas beaucoup mais je pense que niveau interface y'a plus sexy... Rien que le fait de n'avoir que des hashs à la place des révisions...
Et si tu as le serveur qui crashe (et l'admin qui a pas fait de backups), tu apprécieras d'avoir tout en local et pas seulement la dernière version ^^.
Ca c'est un argument qui me parle :) Tu marques un point.
Mais c'est tout de même rigolo cette histoire, je vais relire mon papier m'ai je n'ai pas l'impression d'avoir écrit "GIT c'est de la merde inutile" :) Je dis juste que cela risque d'être une entrave de plus pour les développeurs de modules Drupal. Car je ne sais pas si vous en avez conscience (car je gage que la majorité d'entre vous viennent de planetlibre, et que contrairement au public du planet Drupalfr.org, vous avez les mirettes affûtées en lisant GIT) mais Drupal est une chose, mais il y a aussi les 3500 modules qui sont autant de petit projets (quelques milliers de lignes de code dans la majorité des cas) qui ne sont gérés que par UN seul développeur.
Ben oui mais c'est pas comme si le fait d'être décentralisé gênait ceux qui sont seuls.
C'est sûr qu'il faut un peu d'adaptation en quittant CVS c'était obligatoire, après tant qu'à faire autant donner dans l'outil d'avenir plutôt que dans le truc en fin de vie qu'il faudra quitter dans quelques années...
Puis des gens qui sont capables de coder quelques milliers de lignes de code sont capables d'utiliser git (surtout qu'on peut utiliser bzr ou hg qui sont plus user-friendly pour travailler avec git). Et maintenant avec libgit, git# etc les clients vont fleurir (parceque bon c'est sûr que de devoir passer par cygwin ça devait être pénible).
Mais je suis d'accord pour dire que git est pas ce qu'il y a de plus user-friendly. Hg ou bzr auraient peut-être été plus indiqués.
C'est bien tu es optimiste. J'avoue qu'avec le temps je le suis un peu moins ;p Mais j'espère que c'est toi qui a raison.
Je ne dis pas que tu attaquait git et d'ailleurs ça me ferais une belle jambe que ce soit le cas. Je dis que git a des qualités même quand on est seul sur son programme. C'est tout.
Oui bon, content pour ta jambe mais je répondais à Zanko là :) Ce que je cherchais juste à dire c'est que je m'intérroge sur l'intérêt de GIT pour les modules contribution de Drupal, et tout le monde me répond sur l'intérêt de GIT "hors contexte".
Les DVCS sont très intéressants à plusieurs titres: travail déconnecté, meilleures performances, workflow plus souple. On peut très bien travailler selon un modèle client-serveur type SVN, un modèle réseau de confiance comme Linux ou bien totalement distribué.
La gestion des branches offerte par les DVCS est extrêmement flexible (un gros point fort de Git), un développeur hésitera beaucoup moins à créer une branche avec Git qu'avec SVN. Très pratique pour développer une nouvelle fonctionnalité sans perturber le tronc.
Les DVCS de seconde génération comme Git ou Mercurial ont une architecture extensible permettant d'intégrer des fonctionnalités sympathiques comme la gestion de patchs type quilt, le support des règles de qualités (nettoyer les commits mal formés par exemple) très facilement.
Avant, c'était le développeur qui s'adaptait au VCS, maintenant c'est le VCS qui s'adapte au développeur.
Tout ce que SVN sait faire, Git ou Mercurial savent le faire tout aussi bien si ce n'est mieux. Certes, reste le problème des outils annexes qui n'ont toujours atteint le même niveau de maturité que leurs homologues basés sur SVN mais ça arrive.
Pour les projets existants, on se posera la question de savoir si la migration vaut le coup (pour Drupal, c'est très probablement le cas), pour des nouveaux projets, la question ne se pose même plus.
Un fois encore, je n'ai rien contre les DVCS, je suis même en train de les évaluer pour mes besoins perso. je n'ai aucun problème avec une ligne de commande, donc le niveau des "outils annexes" ne m'embête pas. Mais ici je me place dans la perspective de tous les devs de tous les petits modules contrib. Il y en a déjà tellement qui ont été largués au passage à D6, je crains juste que ce soit encore un peu la même chose avec le choix d'un outils qu'une majorité, qui n'imagine pas de monde en dehors de WAMP (et svn), ne connais ni de la lèvre, ni de la dent.
Maintenant pour les avantages que tu cites, comme je le disais, je suis en cours d'évaluation, et je me ferais ma propre opinion. Car à te lire, je ne vois rien, mise à part le "workflow" qui ne soit pas faisable efficacement avec subversion :)
Sinon c'est Torvalds avec un s à la fin.
Rho oui désolé pour lui :)
Ok je ne reviendrai pas sur les fantastiques possibilités de Git :) Et franchement pour les rudiments ce n'est pas la mer à boire.
Je trouve plutot judicieux d'avoir choisit le même outil de versionning pour le Core et pour les modules. Ne serait ce que pour faciliter les imports de sources modules vers le Core ou encore pour proposer un patch, ceci sans aucune gestion nouveaux developpeurs.
Nota: la récupération d'un dépot distant ce fait avec git clone ..., le pull serait plutôt l'équivalent de l'update.
Pas la peine d'y revenir en effet, depuis que tu m'en as parlé (il y a quelques mois déjà), j'ai déjà bien testé le zinzin et je ne suis plus à convaincre. Maintenant sur l'impact du dit zinzin sur le projet Drupal et particulièrement sur les modules, disons que je suis une cassandre ;-)
Mes 2 cts :
- j'aime bien git (car avec un dépot centralisé comme pour drupal.org, ça permet d'avoir plein de petits commit locaux, dans le trunk ou dans des branches, et un gros push, ou pas, sur le central ensuite)
- tu es sûr que c'est compliqué pour les développeurs de modules ? (et pas les utilisateurs)
- je pense que la question du client user friendly pour le dev retors à la ligne de commande ne se posera plus dans pas si longtemps.
Et pour ceux que ça intéresse, le site de toute la documentation, avec même une version en français, que vous pouvez corriger/améliorer en créant un fork sur ce même dépôt, directement avec git bien sûr ;-)
Je ne pense pas que ce soit compliqué en tant que tel, mais cela demande un apprentissage. Les modules sont en majorité développés (comme tout ce qui est libre d'ailleurs ;-) par des gens qui bossent dans des boites, qui aujourd'hui utilisent majoritairement svn. C'est juste cela qui me semble un peu rapidement "dégagé".
Maintenant comme je le disais, je suis moi-même en train d'évaluer ce système et il faut être honnête, il est tout de même beaucoup plus ésotérique que subversion. Du moins aussi ésotérique que CVS. Un exemple, la création et la gestion de branche/tags n'est clairement pas aussi simple que sous SVN où il s'agit de simple copie de dossier.
Un exemple typique, actuellement tout drupal est sous CVS. Personnellement je n'utilise plus CVS depuis des lustres et j'utilise SVN de manière ultra-quotidienne. A chaque fois que je dois mettre à jour mes modules contrib, c'est un moment chiant que je recule car je ne me souviens plus de rien, comment faire une branche, un tag. En plus mes modules sont sous Subversion, je dois synchroniser cela avec un dossier sous CVS, que j'envoie ensuite sur le serveur... Bref, pas pratique.
Ceci étant dit, je n'ai pas encore regardé git-svn qui peut-être répond à mon besoin d'uniformisation car au fond c'est bien de cela qu'il s'agit. Vu la simplicité du besoin je me moque de l'outil et de ce qu'il apporte de plus que ce que le PPCM de tous ces outils. J'ai juste besoin de gagner du temps, et là, ça m'en fait perdre var bon grès-mal grès, je vais devoir gérer deux outils, les maîtriser et garder cette connaissance vivante pour une valeur ajoutée (point de vue du développeur de module contrib) nulle. Alors je vais essayer de rentabiliser le truc en passant mes dépôts sous GIT mais mes clients eux, ça ne risque pas d'arriver demain...
Ok, ok, mais ton point de vue était déjà clair ;-)
Juste pour ajouter le lien vers la doc git en français et en ligne http://www.alexgirard.com/git-book/index.html
Publier un nouveau commentaire