Un des arguments souvent rencontrés pour justifier l'intérêt de Git est la vitesse des opérations. C'est vrai que c'est agréable de pouvoir commiter instantanément. Pourtant, je travaille régulièrement avec svn, et ce manque de rapidité n'est pas quelque chose qui me gêne beaucoup. Cet argument à lui seul ne suffit pas à justifier le passage de svn à Git.
Les gestionnaires de versions distribués permettent, par définition, de commiter depuis n'importe où (dans le train, le métro, l'avion, les toilettes, etc.). Pourtant, ce genre d'utilisations reste assez marginal, et à l'exception de quelques personnes, c'est une possibilité extrêmement peu utilisée.
On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit), mais ce sont des choix de design de subversion, et un autre gestionnaire centralisé pourrait les corriger.
Pour ma part, je pense que le plus grand apport de git est son aspect bling bling, ce qui permet de mettre entre toutes les mains un gestionnaire de versions avec les avantages (scientifiquement prouvés) du bling bling. Avec subversion, seules les personnes maitrisant le shell et les regexps peuvent accéder au bling bling pour faire des essais. De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale, continuer à suivre les développements fait sur le dépôt officiel et utiliser le bling bling en un clin d'oeil.
Prenons un exemple (fictif) : je suis un utilisateur régulier du logiciel XYZ, j'en suis content, mais je n'arrive jamais à m'y retrouver dans l'écran des options. Je décide donc d'essayer de refaire cet écran, mais comme je passe beaucoup de temps sur la tribune, il va probablement me falloir plusieurs semaines avant de pouvoir proposer un patch à l'auteur.
Premier cas : le logiciel XYZ est versionné avec subversion. Je fais donc un checkout du trunk, et je commence à travailler dessus. Au bout de deux semaines, je commence à avoir une version intéressante de cet écran, mais entre temps, le développement a continué sur le trunk, et une nouvelle option est apparue. Je décide de faire un svn up, mais malheureusement, l'inévitable se produit : un conflit sur plusieurs fichiers. Ce n'est pas très grave, j'arrive à les corriger, et je peux me remettre au travail. J'arrive enfin à un écran des options qui me convient, et juste au moment où j'allais me décider à envoyer mon patch à l'auteur, je me dis que j'essayerais bien d'intervertir 2 options. Je fais ce dernier changement, mais pas le temps de le tester, je pars en vacances. A mon retour, je me rends compte qu'intervertir ces 2 options était une mauvaise idée. Malheureusement, comme je n'ai pas pu commité mes changements, je me retrouve à devoir me rappeler ce que j'avais fait avant de partir pour pouvoir annuler ces changements. Ecœuré par tant de dur labeur si ardu, j'abandonne.
Deuxième cas : je fais un svn export du même dépôt, puis je créé un dépôt svn local pour gérer mes avancées. Je peux tranquillement travailler sur mon écran d'options. Quand j'arrive à quelque chose de convaincant, je propose un patch à l'auteur, qui le refuse, car celui-ci ne s'applique pas sur le trunk. J'essaye alors de me synchroniser avec le dépôt officiel, mais entre les nombreux conflits et le trunk qui n'arrête pas d'évoluer, je finis par abandonner :(
Maintenant, le même scénario avec Git se serait beaucoup mieux passé. En effet, j'aurais eu exactement les mêmes problèmes : merges qui echouent, patch refusé parce qu'écrit n'importe comment, etc. Par contre, il y a une difference de taille : le bling bling intégré. Après de longues heures de dur labeur, au lieu d'abandonner degoûté devant l'ampleur de la tâche, j'aurais simplement fait :
$ git config --global color.diff.old blink\ cyan\ magenta
$ git config --global color.diff.new blink\ yellow\ green
$ git config --global color.diff auto
$ PAGER= git diffDevant la beauté du résultat, je serais reparti avec plus d'ardeur qu'un gnu en rut devant un manchot femelle, et j'aurais terminé dans la joie et la bonne humeur mon patch.
Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages (maitriser les regexps et les pipes), mais imaginer que vous vouliez vous mettre à plusieurs pour proposer une nouvelle fonctionnalité majeure pour votre logiciel préféré. Comment programmer dans une ambience saine et conviviale sans un minimum de bling bling ?
Pour moi, la grande force de git est là : pouvoir utiliser du bling bling sans maitriser des outils d'une complexité affolante. Le bling bling est la seule façon sereine de faire des développements expérimentaux tout en continuant à se synchroniser sur la base de code officielle. Git casse cette barrière entre ceux qui ont savent faire leur bling bling eux-mêmes et ceux qui ne savent pas.
# C'est tout de suite plus clair
Posté par JereMe . Évalué à 4.
# Deux questions
Posté par Sébastien Koechlin . Évalué à 3.
- Est-ce que tu pourrais faire une capture d'écran du bling bling ?
- Est-ce que ça tourne avec les drivers libres des cartes ATI ? Ou bien uniquement avec les drivers proprios ?
[^] # Re: Deux questions
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Non, il s'agit d'un bling bling dynamique. À la limite un screen cast...
- Est-ce que ça tourne avec les drivers libres des cartes ATI ? Ou bien uniquement avec les drivers proprios ?
Évidemment ! À quoi cela servirait que git apporte le bling bling à l'utilisateur lambda, si c'est pour ne pas tourner sur la plupart des machines ?
git ne demande qu'un terminal digne de ce nom pour activer toute la puissance du bling bling.
# J'ai pas compris la différence
Posté par Zenitram (site web personnel) . Évalué à 2.
- Le blink-blink, je l'ai, SVN me fait un diff nickel, de la même manière que GIT. Ton reproche s'adresse au diff, pas au gestionnaire de version.
- le blink-blink, je l'ai avec mon GUI SVN. Je n'ai jamais tapé une ligne de commande SVN.
- Dans le train, je travaille tranquillement, et je commit en rentrant à la maison. Si j'ai envie d'avoir des snapshots, je dis juste à mon GUI SVN de me faire un commit sur un serveur SVN local que mon GUI créé en un clic.
Donc bon, j'ai toujours pas vu l'avantage que tu veux absolument trouver à GIT pour ton utilisation : tout ce que tu reproches à SVN et que tu préfère dans GIT, tu peux faire de la même manière avec SVN.
Le seul (mais pas des moindres pour des gros projets) avantage de GIT et d'avoir une décentralisation des branches. C'est bien pour un très gros projet comme Linux, mais pour 99.999% des projets c'est inutile.
Linus T. a fait un soft qui lui convient, pour son petit (sic :) ) projet qui lui tien à coeur. Ca ne veut pas dire qu'il soit adapté à tous les projets.
[^] # Re: J'ai pas compris la différence
Posté par Dufréchou Laurent . Évalué à 2.
-Commiter dans le train et merger tes commits avec la branche principale en un clin d'oeil.
-Commiter en local et servir en local tes commit avec tes collègues avant de faire un commit sur le serveur principal
-Uncommiter...
-Faire une branche pour la merger ensuite sans douleu
J'ai fait les trois premiers points sous bazaar (meme principe que GIT)
et le fait de pouvoir commiter en local avant de commiter sur le trunk a distance c'est vriament trés trés pratique!
Tu peux faire des branches facilement et remerger tout ca aprés sans avoir les même soucis que sous SVN. (j'avais testé une fois une branche, c'etais l'enfer...)
En gros sous bzr ou GIT tout est branches, et c'est bien géré des le début.
En gros des que tu bosses a plusieurs sur différents sites, c'est un peu mieux que SVN.
Maintenant il manque qd même des GUI à la tortoise sous windows qui est qd même excellent. Pour moi c'est le seul defaut et de taille. Les collègues sous windows ont BESOIN d'un gui click and do efficace a la tortoise. Apparament c'est en cours, tortoise-bzr, tortoise-hg (pas de tortoise git :p )
[^] # Re: J'ai pas compris la différence
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Ainsi, tous les arguments liés à la centralisation de SVN tombent à l'eau.
[^] # Re: J'ai pas compris la différence
Posté par Temsa (site web personnel) . Évalué à 5.
* En un an, pour les différents rewrite sur mon projet tournant sur SVN, voici les scenarii :
- Je ne bosse qu'en local, à la fin je tente un merge avec ce qui se trouve sur le serveur, au final j'en merge 75% et par erreur pouf, je commit le reste par dessus les commit d'origine : oui, evidemment, j'avais eut le tort de déplacer un repertoire ou deux, et comme je les ai déplacé avec un drag end drop et non exporté/supprimé/créé/reimporté, bah les .svn pointaient pas au bon endroit, ca se voyait pas, du coup j'ai fait du caca, et j'ai absolument pas mergé cette partie, sasn oublié que le commit final m'a demandé de faire 150 cleanup et 75 release lock ....
Après je fais un appel au test des 25 autres deeloppeurs pour verifier que toutes les dernière modifs sont ok, et savoir celle qui ne le sont pas
- Je me dis, j'ai progressé avec svn, maintenant j'ai qu'a utiliser le super système de branche. Je créé une branche je bouge des repertoires, mais la je me fais pas avoir, dans mon tortoise (ou eclipse, meme combat) je fais un export avant, je créé la destination, je reimporte les fichier au bon endroit et je supprime l'original.
Ya sans doute un client svn (aka, celui de base en ligne de commande) pour gérer les "mv" mais bon, mon but est de faire une manip que les autre pourront faire après sans se poser trop de questions (il auront pas envie d'ouvrir une super console windows pour aller jusque dans leur workspace, s'inquieter du path, etc.).
Là, je dois merger ma branche et curieusement ca veut pas merger avec le tronc. Pourtant je lui donne bien la dernière version de ma branche a merger avec la dernière version du tronc.
Marche pas.
J'abandonne : export de la branche, redownload complet du tronc dans un autre repertoire, je colle par dessus, et je regarde ce qu'il m'indique avoir besoin de committer. Bon evidemment, poyur les fichiers que j'ai deplacé, je tourne à la comparaison fichier par fichier sur les plus importants, je croise les doigts pour le reste. J'ai des charges à tenir, et comme la dernière fois, ça passera par un "svp testez tous, je viens de faire du bordel". Evidemment, il resta quelques problèmes par oubli de fichier, et certains fichiers sotn resté en double dans l'arborescence pendant 2 semaiens (oubli de suppression).
- Je me dis on va faire les chose bien, cette fois je vais lire la doc. pis déjà, pas de répertoire à déplacer cette fois, ouf. Je dis à mes chefs qu'on va faire une doc pour qu'on puisse industrialiser le processus. Je lis la doc de SVN, et je comprend grossomodo ce qu'il faut faire.
Je me fais un petit teste en local, et j'arrive a faire un merge en ne modifiant qu'un fichier, puis un repertoire. Bien! Apprendre à le faire ne m'aura que couté une demi journée.
Vu que c'est pas méga intuitif (et oui, n'oublions pas de merger la version n-1 de ma branche avec la dernière version du tronc, ou le contraire, je sais plus, ou alors c'est le n-1 de la version qui sépare le tronc de la branhce ? je sais plus), je fais meme un petit screencast car ca va plus vite que de faire une doc à laquelle personne n'aurait rien compris pour faire le merge (cf. doc svn).
Bon finalement je fais ma branche, puis je dois passer sur une autre partie du projet, un collègue doit prendre ma suite, evidemment, le jour du merge, il ne regarde pas mon screencast car pense que le merge de branche est assez naturel et au final, apres une journée de galère arrive à merger (en plus j'étais en vacances ce jour là)... à coup d'export/import.
J'ai appris plus tard qu'il était dejà spécialiste des override and commit et de raler sur les gens modifiant le même fichier que lui.
- Dernièrement : je sais que faire une branche est un gros bordel, ma video s'est noyée dans le wiki dans le wiki de doc developpeur, mon planning est super serré (faire des rewrite est considéré uniquement comme un cout, rarement comme quelquechose permettant à l'application de mieux tourner ...). je commence une experience d'un dev avec un risque que ça ne fonctionne pas.
Au pire j'abandonne cette idee au bout de 2 jours. Ce qui se produit. Je continue donc le reste et override and update les fichiers que j'avais modifié.
Pas de merge pour cette partie.
Il y a 2 semaines, le point bloquant empêchant mon "developpement experimental" de fonctionner est résolu, et coup de bol j'ai 2 jours de dispo pr le reintegrer.
Evidemment, comme j'ai pas fait de branche, tout en local (je deteste ça), bah hop je n'ai plus rien. La modif ne sera donc jamais faire (ou pas avant de long long mois).
Ca c'est passé comme ça parce que je savai que j'aurai pas le courage de remerger la branche et de faire les deplacements de repertoires et fichiers via svn (je ne sais toujours pas comemnt faire d'ailleurs).
Avec un gestionnaire de version avec un système "naturel" j'aurai pas eut ce problème.
* En dehors des rewrite, notre svn derrière apache sur notre serveur de dev semble avoir des problèmes incompréhensibles qui plantent les clients svn.
Dans ce cas, on se loggue sur le serveur, on passe root, on redemarre l'apache, qui n'était pas tanké pour autant, mais qui laisse des connexions ouverte sur le svn, plus rien ne bouge: la plupart du temps ça arrive sur les gros commit ou les checkout, ou quand plusieurs developpeurs font pas mal de petits commits/updaet en même temps.
Evidemment il faut redemarrer les clients (dans eclipse ca veut dire fermer et rouvrir eclipse, c'est pas comme si c'etait immédiat).
La semaine dernière le svn+apache plantait toues les 15-20 minutes. J'arrivais même pas à finir mon commit avant que ça replante, evidemment ça me laissait des lock, et il me fallait faire des clean up et des release lock, j'ai même eut droit à des erreurs sur le cleanup me demandant de faire des exports/suppression/update/reimport/diff/commit des fichiers concernés.
Je n'ai perdu que mon après midi... pas grave.
Bref: si la plupart des problèmes viennent de notre utilisation de "noob" de svn, il nous créé bien des problèmes et nous fait perdre beaucoup de temps à cause de ses fonctions peu pratique et absolument pas naturelles (j'avais vu une conférence chez google d'un certain Linus T. disant exactement la même chose, il a 10000 fois raison là dessus... d'ailleurs ça l'a décidé à faire son propre système de gestion de version, un certain Git je crois !).
Pourquoi est on toujours sous SVN alors ? D'abord, car les décideurs ont du mal à comprendre le problème, ensuite et surtout parcequ'on manque d'intégration sous Windows d'autres système, comme des DVCS, dont ils ne voient pas l'intérêt (personne n'a besoin de commiter dans un avion là... par contre ils s'en foutent que le serveur de dev de svn marche à mi-temps...).
Bah personnellement, les DVCS, j'en voit l'intéret : faire sa branche dans son coin, ou travailler à 2 avec un pauvre partage Windows (je sais c'est pas le bon endroit pour parler de cet OS, néanmoins je suis cantinné dessus au boulot, à cause d'exchange... et qu'on me parle pas du plugin d'evolution avec lequel j'ai terrassé les serveur de courrier lors de mes derniers essais !), c'est très simple. Le serveur de dev marche pas ? Pas grave je commit sur un serveur de secour, ou sur un partage sauvegardé, je mergerait plus tard.
Le problème :
Bazaar: sous windows, existe en standalone, mais si on veut une integration eclipse, c'est python+bazaar+plugin bazaar+plugin-eclipse+config plugin qui n'est pas encore tout à fait au point, et il faut rajouter : svn-patché + plugin bazaar pour pouvor tenter de faire un checkout du svn dans un repo bazaar ... Le tout pour se rendre compte que vu que je peux pas me connecter en https + user/mot de passe, de toute façon j'y arriverai pas.
Git : install windows ok, integration eclipse: moyen (derivé du plugin de bazar de memoire), j'arrive meme pas à lef aire tourner, et je sais meme pas comment faire mon checkout à partir de SVN même si je sais Git capable de le faire.
Mercurial: pas tenté mais semble du même accabi que les 2 précédents.
J'ai pas testé les tortoiseXXX pour les DVCS cités, mais une intégration à Eclipse serait tout demême bien plus pratique (par exemple pour l'intégration avec Mylin)
Ces dvcs sont prometteurs, sympathiques et tout, mais il leur manque une bonne intégration sous windows (evidemment, je préfèrerais bosser sous Linux), et la possibilité de travailler facilement avec un serveur SVN (pour pouvoir montrer que la transition est interessante) sans avoir de limite (comme https/login & mdp) et avec une installation en demandant pas 1 mois de recherche et de bookmark pour y arriver.
J'attend vraiment une certaine maturation de ces produit pour leur sauter dessus dés qu'un de ceux-ci peut m'aider dans mon travail. En attendant, je râle presque quotidiennement sur notre SVN :/
[^] # Re: J'ai pas compris la différence
Posté par Temsa (site web personnel) . Évalué à 0.
[^] # Re: J'ai pas compris la différence
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Tu n'as pas essayé les commandes ci-dessus pour proférer de telles insanités !
Pour le reste, je dirais:
Humour et Plagiat.
# Oubli
Posté par plusplus . Évalué à 1.
[^] # Re: Oubli
Posté par Marc Poiroud (site web personnel) . Évalué à 6.
Si tu veux commiter ta branche avec la boulangère, faut attendre 9 mois pour voir le patch et là pas moyen de uncommiter !
[^] # Re: Oubli
Posté par Sylvain Sauvage . Évalué à 9.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.