URL: https://linuxfr.org/users/gaetan_63/journaux/recherche-gestionnaire-de-version-id%C3%A9al Title: Recherche gestionnaire de version idéal Authors: Stibb Date: 2011年02月02日T18:22:51+01:00 Tags: Score: 0 Bonjour, je suis à la recherche d'un gestionnaire de version idéal (que je vais appeler GVI), c'est à dire, qu'il me permette de faire tout ce que je veux, sans m'induire en erreur, que chaque chose soit facile à utiliser et le plus simplement et intuitivement possible. Je ne veux pas avoir à taper "man" pour faire des actions simples (pour moi, un merge entre une branche A et une branche B avec un fichier qui a changé de nom EST une action simple que l'outil doit gérer automatiquement). Pour tous les afficionados de GIT ou autre, je suis de votre coté. Je pousse pour que l'on adopte GIT dans ma boite, mais voila, GIT est trop complexe, et trop souvent source d'erreur. On ne veut pas, je ne veux pas, perdre du temps sur des actions simple. Si une interface utilisateur permet de rendre toutes les taches faciles, pourquoi pas. Mais pour l'instant, que ce soit "git gui/gitk" ou qgit, chaque interface est soit trop limité (pas possible de merger, ou alors on a des vues beaucoup trop complexes à chaque fois). J'espère énormément de egit pour eclipse, vu que c'est mon environnement, mais il n'est pas encore exploitable (on ne peut pas naviguer dans l'historique d'un dossier par exemple). La présence d'une interface graphique est indispensable. Pas question de me taper une ligne de commande pour la vie du code "normal" (je n'ai rien contre revenir sur la ligne de commande pour une action complexe, mais pour une action que j'estime normal tout doit etre abstrait par une interface propre et efficace). Bref. Pour l'instant, je suis sous CVS. Ca sera ma base de la réflexion. CVS a vite ses limites, mais l'utilisation est simple. Le projet est assez classique: - on commit régulièrement dans la mainline pour les dev en cours - si une feature est impactante, on créé une branche que l'on maintient à jour à coup de merge - on merge sur la mainline quand le dev est fini. - on créé une branche de release quand le code est pret à être livré. - les bug fix sont appliqués sur la branche de release et sur la mainline. Jusque la, que du tres classique. Bref, dites moi ce que vous en pensez, mais j'évalue les 3 gestionnaires de version que je connais: - CVS - SVN (1.4, il parait que la version 1.6 corrige certaines choses avec les bons outils, mais je n'ai pas pu l'évaluer) - GIT J'ai utilisé longtemps Clearcase, mais je vais volontairement l'oublier pour la simplicité des débats. Gestion des fichiers ============ - la manière dont CVS est fait, les merges de ma branche dérivée est simple au début, puis au fur et à mesure que le code diverge, les merges sont de plus en plus risqués. Un renommage de fichier et le merge automatique est mort. -> Point 1 : je veux que GVI gère les renommages de fichiers nativement A priori, seul GIT s'en sort correctement. SVN permet à la limite avec svn rename, mais les merges foirent lamentablement par la suite une fois sur deux. CVS on oublie, Clearcase aussi. Un merge facile =========== - pour CVS, je créé à chaque mise à jour de la branche avec les changements de mainline un tag, que j'utilises comme racine ensuite pour le merge suivant. Ca m'évite de me taper les meme conflits à chaque fois. Il faut de la discipline pour créé ce tag (suffit qu'un developpeur oublie de faire ce tag et hop, c'est mort), mais ça marche très bien. Je n'ai aucune difficultés à maintenir une branche en parallele de la mainline; -> Point 2 : je veux que GVI gère automatiquement les évolutions des branches. Je lui dit "merge la branche "new_feature" sur la mainline, et il me fait tout tout seul, il sélectionne les commit, trouve l'ancètre, fait tout proprement et tout seul. Pareil, si je lui dit "met à jour la branche "new_feature" avec la mainline, il trouve tout seul les changements appliqués sur mainline depuis le dernier merge sur "new_feature" Alors, là, CVS s'en sort bien avec la discipline de faire des tag à chaque fois qu'on effectue un merge. SVN aurait pu s'en sortir majestueusement, mais alors là, c'est vraiment la merde avec un M majuscule: - il faut retrouver le fichier dans l'arborescence "branch/chemin/vers/le/fichier.cpp" le fichier ou le dossier que l'on souhaite merger. Ce fonctionnement est nul. C'est dans l'autre sens que l'information doit être affiché à l'utilisateur : Je veux qu'il m'affiche (la UI) toutes les branches pour le chemin/fichier concerné, je ne VEUX pas à aller rechercher dans les méandres des chemins branches/tags/trunk, la UI doit être suffisamment maline pour m'afficher les bonnes informations. CVS le fait parfaitement. -> Point 3 : lors d'une demande de merge, l'interface n'affiche que les noms des branches ou des tags, et pas ces foutus chemins trunk/branch/tag. Je veux une liste, comme le fait la boite de dialogue "Compare With Branch or Tag" du plugin CVS d'éclipse. Pour un chemin donné, lors d'une demande de merge ou de comparaison, il va m'afficher tous les noms des branches, avec un champs de recherche, etc. C'est parfait pour moi. - avec SVN, il faut choisir tous les commit entre le précédent merge et le merge actuel. Il n'est pas foutu d'enregistrer une information qui évite ce niz à erreur? Il semblerait qu'avec un repository en SVN 1.6 + les outils de collabnet, ce comportement soit atteint avec SVN, mais je n'ai pu tester. -> Point 4 : je veux juste lui indiquer le nom de la branche (ou du tag) source et la branche destination et il me merge tout proprement, prennant les commit pas encore appliqué mais laissant les autres. Lors de tous mes tests avec GIT, ce comportement était atteind à la perfection. Centralisé ====== Oui, la mode est au décentralisé, sortir tout sur son ordi, c'est cool. Mais je n'en veux pas. Je ne veux faire que 2 opérations au quotidien : checkout, puis checkin. Pour les branches, "Create Branch", "Switch Branch" et "Merge" me suffisent. Le reste je n'en veux pas. Les "hard reset", "cherry pick", c'est bien cool, mais c'est le meilleur moyen d'exploser son repository local (ca m'est déjà arrivé, et détruire aussi facilement son travail parce qu'on fait un hard reset en pensant que c'est le moyen de sortir une version ancienne du code n'est tout simplement pas acceptable). -> Point 5 : GCI est centralisé. Chaque branche créé est sur le serveur et peut être utilisé pour un build automatique directement. Il semblerait que l'on puisse utiliser GIT en centralisé, mais il ne reste que lorsque l'on effectue un checkin, ca ne modifie que le repo local. Je n'en veux pas. Pareil, envoyer ca branche de développement sur le repository distant est trop compliqué (les branches de dev peut etre utilisé pour des build automatiques sur des plateformes que n'ont pas forcément les dev). Pour ce point, GIT est inutilisable. SVN et CVS remplissent leur taches. Commit atomique =========== SVN est parfait de ce coté là. Chaque commit est facilement resortable, dans son ensemble. Avec CVS, pas possible, ou alors il faut jouer avec la date en cours, ou avoir appliquer un tag sur l'ensemble du code -> point 6 : un numéro de version unique permet de revenir à une anciene version de l'arbre du code. GIT permet d'avoir un id unique par commit, meme si je trouve ca nettement moins élégant, c'est accepté Intégration dans Trac ============= On utilise trac pour notre bugtracker. CVS n'est pas bien intégré, on ne voit pas les changeset. C'est extremement domage. SVN permet d'avoir les changesets affiché dans la timeline. C'est parfait. Intégration dans eclipse =============== Parce que c'est mon environnement et que je suis égoiste. GIT est intégré, mais le code évolue beaucoup CVS est intégré, et n'évolue plus. SVN est intégré, et il y a différentes combinaison possible (JNI ou Pure Java, Collabnet ou pas, ...). Bon, moi je trouve l'intégration SVN + Collabnet exploitable, les merges sont assez simple meme s'ils pourraient etre plus direct avec l'affichage des noms des branches. Intégration dans vim, gedit, xemacs, visual studio ======================= on utilise ici tous les environnement de dev (chaque developpeur à le siens). Il faut donc que chaque environnement ait une interface mature. Pour ceux qui n'utilisent pas d'intégration, une interface standalone doit etre dispo (comme cervisia ou kdesvn). Je n'ai jamais réussi à utiliser gitk/git gui, déjà il y a différent outils avec des interfaces différentes. Il me faut un outil clair et précis. L'historique ========= La gestion de l'historique du code et son affichage proprement est priomordiale. Un changement peut avoir été fait et on veut pouvoir revenir à un ancien code facilement. Pour l'instant, CVS avec eclipse est parfait. SVN est exploitable lui aussi. On a acces, depuis eclipse, aux options "compare with" et "replace with", qui affichent les branches et les tags. Sur ce point la, seul CVS est parfait. GIT permet de naviguer dans l'historique, mais sortir une version ancienne est un cauchemard. On ressort une version ancienne, et l'affichage de l'historique par exemple est completement changé, on ne peut plus revenir a la version actuelle facilement. Ou alors on se prend un conflit dans la tete pour une raison X ou Y. Je veux une option "Replace with version XXX" qui ne pose pas de question. De plus, l'intégration dans eclipse manque de l'option de pouvoir comparer un dossier (et pas un fichier) avec une ancienne version. Corrolaire : visualisation =============== Je suis quelqu'un de visuel. Je veux pouvoir voir les choses pour les appréhender. Avec CVS, les tags sont par fichier. Avec graphview, j'arrive à voir pour un fichier donné une belle arborescence. Mais il me faut pour l'arbre du code complet. SVN le permet... presque. Les tags sont affiché comme des branches... Non, un tag doit être appliquer sur une branche. Pour moi, tag = numéro de commit. Si seulement ils avaient offert la possibilité de nommer un commit (avec un "tag"), s'aurait été idéal. Alors, le plugin "revision tree" de trac permet d'afficher les commit sur les différentes branches, ce qui est tres bien. Avec un repo > 1.6 il parait qu'il y a même les flèches de merge, mais je n'ai pu tester. L'idéal de ce coté, c'est GIT. On a toutes les branches visibles. Mais c'est le repository local et pas le repository central qui est affiché, ce qui est problématique. Et après, les possibilités d'interaction, en tout cas avec les interfaces, sont catastrophiques. Je sors telle version, et hop, toutes les autres disparaissent de la vue, ou j'ai une grosse erreur de merge et il refuse par la suite d'effectuer les opérations que je veux. Innexploitable. Voila, vous comprendrez, pourquoi pour l'instant on reste sur CVS. C'est paradoxale vu la quantité de médire qu'il y a dessus, et je suis le premier à dire que CVS c'est vraiment de la merde. Mais un truc mieux, ce n'est pas immédiat. - SVN est le candidat naturel, mais les merges ne sont pas plus simples. Je suis désolé, mais si je veux merger le fichier suivant : repo/project/trunk/chemin/vers/fichier.cpp dans une branche donner, je ne veux PAS devoir aller chercher à chaque fois tout le chemin repo/project/branch/nomdelabranche/chemin/vers/fichier.cpp. Inacceptable. Je veux une boite de dialogue qui me dise les branches/tag candidates pour ce fichier. Point. Ce n'est pas dur, CVS le fait parfaitement. Et puis désolé, le fait de pouvoir commiter dans un tag avec SVN me sort par les oreilles. Un tag est un tag, ce n'est PAS une branche. - GIT. Avec une bonne interface graphique, GIT serait l'idéal. Vraiment. Mais voila, on peut trop facilement exploser tout son travail en 3 secondes, que ça restera pas envisageable. Je sais, je sais, on PEUT l'utiliser tous les jours, mais voila, je ne le ferais pas. Pour moi un outil doit etre simple et efficace, et GIT est completement l'inverse : complexe et exploitable uniquement en le prennant avec des pincettes.

AltStyle によって変換されたページ (->オリジナル) /