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.
Journal Recherche gestionnaire de version idéal
2
fév.
2011
# hg
Posté par B16F4RV4RD1N . Évalué à 10.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: hg
Posté par pasScott pasForstall . Évalué à 3.
MacHG est redoutablement efficace pour les maceux.
Tu peux l'utiliser comme svn si le decentralise pur ne convient pas, c'est juste beaucoup plus souple, ce qui te sauve la vie les qq fois ou ls souplesse est requise.
Et dans l'ensemble la philosphie de design est bien plus propre que celle de git (ie, on fait les choses bien plutot que de hacker des trucs les uns sur les autres).
Bon, apres, les gouts et les couleurs, mais mercurial parait un juste compromis entre git et svn.
Et le support du tooling est plutot bon.
Tous les builds servers etc supportent mercurial, atlassian vient de racheter bitbucket donc on peut raisonnablement penser qu'ils vont le supporter longtemps dans leurs produits.
Et le plugin eclipse est achement mieux gaule. Au dernieres nouvelles, jgit ne pmet toujours pas de faire un diff dans la team view d'eclipse, ce qui le rend purement et simplement inutile.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: hg
Posté par El Titi . Évalué à 2.
Tu confirmes ?
[^] # Re: hg
Posté par pasScott pasForstall . Évalué à 1.
Ce qui est etonnant, considerant que hg est beaucoup plus dans la philosophoe de design apple que git.
J'ai ouvert ma feature request, ainsi que beaucoup au bureau.
La gm seed du 4 est sortie ya qq jours, hg est toujours pas dedans, donc je doute que ca arrive sous peu.
C'est apple, un beau jour, ils diront que xcode c'est revolutionnaire parce que ca supporte hg :)
L'interface svn dans le 3 etait plus que bizarre, ca change beaucoup dans le 4, mais j'ai pas pu teste vu que tous mes projets perso son hg et c'est perforce au taff (via le bridge mercurial pour ma part).
Apres, vu la qualite de machg, c'est pas tant une tare que ca.
Meme sous eclipse en fait j'ai laisse tombe le plugin poussif pour machg (sauf eventuellement un check sur l'historique d'un fichier de temps a autre).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: hg
Posté par El Titi . Évalué à 2.
Lorsque tu dis que tu as laissé tombé le plugin poussif tu parles de celui de Hg "achement mieux gaulé" que celui de git.
Tu peux préciser (on envisage un passage sous Hg au taf).
[^] # Re: hg
Posté par pasScott pasForstall . Évalué à 0.
Le plugin en question doit etre hgeclipse ou un truc du genre.
C'est pas complique, ya 2 plugin hg pour eclipse, un pourri, abandonne, et l'autre qui marche.
Mon utilisation: on utilise perforce au taff, et j'aime pas du tout. Du coup je clone les repo sur lesquels je bosse localement, je bosse contre mon mercurial et je pousse le soir vers p4.
Je branche de temps a autres, genre quand j'ai un gros refactoring/clean up a faire "under the radar" sur un projet ecrit avec les pieds, ca me permet de bosser sur les deux a la fois, ensuite je merge le tout et, paf, le projet nettoye.
Leplugin fait a peu pres tout ce que tu veux qu'il fasse. Le tout integre a la team perspective.
Push pull commit merge diff, pour le basique, evidemment.
Historique par fichier, switch vers une aute branch, tag, bookrmark, revision. Update vers ce que tu veux, tu peux brancher et meme faire un hg serve. Ca a l'air de supporter des extensions, mais je peux pas t'en dire plus, jamais utilise.
Leur organisation des repos est pas la plus facile a utiliser, mais ca reste tres raisonnable. Ils ont une vue hierarchique des repos qui a un interet certain.
La raison pour laquelle il parait poussif est simplement parce que c'est un plugin eclipse, d'une part (ca reagit aussi vite que subclipse), en comparaison a machg, ca parait lent. Disons que les qq secondes de lag sont acceptables quand tu fais 2 commits par jour avec svn, pas quand t'en fait 15 avec un dvcs.
L'autre raison est lie a mon utilisation. On utilise maven, je dois avoir qq chose comme 25 ou 30 projets dans mon workspace, la plupart sont fermes en general (m2eclipse est assez lent, plus encore que maven tout court), du coup je ferme tout la plupart du temps.
Et projet ferme = pas de support hg avant que t'ouvres le projet. Et ouvrir un projet, c'est lent, bien plus que de fair cmd tab et passer dans machg.
Une autre raison aussi, c'est que l'organisation en projet d'eclipse de projets maven colle pas trop. En gros, un projet maven avec 4 modules va te donner 4 projet, qui vont pas forcement apparaitre comme etant etre dans le meme repo.
Disons que si t'as 2 projet mvn, venant de 2 repos different, avec chacun 3 modules, tu vas avoir 6 projets, et t'auras aucune idee de quoi vient d'ou. Les workings set permettent de mitiger ca, mais ca montre tres vite ses limites.
Ca c'est plus un probleme d'eclipse qu'autre chose cela dit, t'auras le meme pb svec git, svn ou cpold.
Le gros probleme d'egit, c'est surtout qu'il est en pre alpha 0.1.
Pas de support de diff pour un plugin pareil, c'est vraiment redhibitoire, les mecs sont cense bosser dessus cela dit.
On a aussi envisage des dvcs au taff recemment, on a fini par laisser tomber (d'autres chats, plus gros, a fouetter avant), mais ce qu'il en est ressorti:
- les boss ont dit "on veut git" parceque ce sont des geeks cli hardcore
- on a aussi zieute hg
- on s'est rendu compte que le support hg dans le tooling est aussi bon
- on a bien vu que git est tres dur a utiliser, et que ca peut etre un gros probleme de former tout le monde
- niveau features, hg et git se valent largement pour une boite ou tout le monde est dans le meme batiment.
- on est un java shop, donc pas de support eclipse = thanks, but no thanks
- hg est beaucoup plus simple, vraiment, plus propre, donc si la migration se fait, elle se fera vers mercurial.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: hg
Posté par Antoine . Évalué à 2.
# Interface graphique
Posté par DLFP est mort . Évalué à 10.
J'ai jamais trop compris l'intérêt de l'interface graphique pour ça, les seuls moments où j'en utilise une c'est pour voir l'historique des commits (avec tig).
Je comprend pas comment tu as déterminé que publier sa branche était plus facile avec SVN. Sans compter les merges qui sont impossible sauf à suivre une organisation très stricte des branches, ne merger que dans un sens, etc.
Et sinon, tu devrais essayer Mercurial.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Interface graphique
Posté par Nahuel . Évalué à -1.
[^] # Re: Interface graphique
Posté par El Titi . Évalué à 6.
Dans ma boîte, depuis que les interfaces graphiques ne sont plus utilisées (en gros depuis le passage à git) il n'y a plus de commits faits n'importe comment.
Comme Git est inutilsable autrement qu'en ligne de commande une limitation devient une feature c'est ça ?
Ca me rappelle les zélotes de SVN qui ne jurent que par l'intégration continue simplement parce que SVN est incapable de gérer plus d'un branche correctement.
[^] # Re: Interface graphique
Posté par DLFP est mort . Évalué à 2.
Ce n'est pas une feature − je ne travaille pas pour Microsoft − mais ça a confirmé mon idée qu'il fallait éviter ces interfaces graphiques.
Je ne vois pas trop le rapport avec l'intégration continue et l'absence de branches surtout que je l'utilise particulièrement avec git et des branches. Tu veux peut-être juste parler de l'absence de versions ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Interface graphique
Posté par Fabimaru (site web personnel) . Évalué à 6.
J'ai jamais trop compris l'intérêt de l'interface graphique pour ça, les seuls moments où j'en utilise une c'est pour voir l'historique des commits (avec tig).
J'utilise CVS et SVN. Sous Windows.
Je n'ai jamais trop compris l'intérêt de se passer de l'interface graphique pour ça. C'est intégré à l'Explorer (TortoiseCVS/SVN) et à mon IDE (j'ai écrit un mini-plugin pour Visual Studio qui appelle Tortoise depuis l'éditeur de texte), donc au quotidien c'est vraiment très pratique à utiliser.
Chez moi où j'ai uniquement du Linux, je n'ai pas trouvé de manière d'utiliser SVN aussi sympa (ce qui m'embête bien).
La ligne de commande de CVS et SVN, c'est comme celle de "ps", j'ai jamais pu me rappeler des options. Et regarder souvent le "man", ça me gave. Je préfère avoir les options les plus courantes dans une GUI.
[^] # Re: Interface graphique
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
_Le plugin SVN pour Eclipse ne marche plus, rien que pour chez moi, malgré les désinstallations/réinstallations.
_Chez mes partenaires pour un projet, un verrou placé sur un fichier avec Eclipse était impossible à retirer, sauf en passant par la ligne de commande.
_Ne pas commiter les changements du .classpath (le plugin pour Eclipse commite automatiquement les changements pour ce fichier, à chaque fois ça fout en l'air la configuration du projet chez chacun).
Heureusement, les joies de SVN ne se limitent pas qu'à un plugin réussi pour un IDE parfait.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Interface graphique
Posté par El Titi . Évalué à 2.
Ne pas commiter les changements du .classpath (le plugin pour Eclipse commite automatiquement les changements pour ce fichier, à chaque fois ça fout en l'air la configuration du projet chez chacun).
Ca le fera quelque soit l'outil.
Pourquoi le gérer en conf s'il est propre à chaque workspace ?
_Chez mes partenaires pour un projet, un verrou placé sur un fichier avec Eclipse était impossible à retirer, sauf en passant par la ligne de commande.
Le fonctionnement par lock ne correspond pas à l'usage par défaut de SVN.
Tu as essayé tous les plugins ?
vous utilisez Subversive ou Subclipse ?
[^] # Re: Interface graphique
Posté par pasScott pasForstall . Évalué à 1.
Ou tout simplement, au premier commit, vue synchronize (que tu utilise a chaque commit j'espere), tu peux faire un ignore de la.
Note que tu auras strictement le meme probleme avec git, mercurial, perforce ou cpold.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Interface graphique
Posté par pasScott pasForstall . Évalué à 2.
Un autre point a prendre en compte: en entreprise, on travaille en equipe.
Forcer les gens a utiliser une cli parce saymieux, c'est generalement pas la meilleure maniere de faire accepter un outil nouveau, et forcer des gens pas a l'aise avec une cli a utiliser git, attends toi a avoir une catastrophe dans ton arbre de source. Ou avoir une forte baisse de productivite sur certaines personnes.
Si ces gens sont mal a l'aise a l'idee de commiter en cli, ils vont avoir une reticence a utiliser git. Et un developpeur mal a l'aise avec son gestionnaire de version, c'est un accident qui attends d'arriver (comme disent nos amis mangeurs de hamburger).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Interface graphique
Posté par DLFP est mort . Évalué à 2.
L'interface graphique, en tout cas celle qui était utilisée pour Subversion, semblait pousser à commiter n'importe-comment. Je me souviens aussi qu'elle reprenait par défaut le message du dernier commit, ce qui comme on peut s'en douter donnait des suites de commits aux messages identiques.
Je constate d'ailleurs que suite à la migration, on utilise des interface graphiques ou des intégrations aux IDE pour plein de choses sauf les commandes type pull, push, add, commit.
Après, la disparition des mauvais commits est peut-être aussi due à un meilleur niveau.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Interface graphique
Posté par pasScott pasForstall . Évalué à 0.
Ceux qui commitent comme des porcs en faisant un "mark as merged" au premier conflit (deja vu ca), c'est pas en leur compliquant la tache que tu vas regler le probleme.
Ils vont faire gaffe au debut, prendre leur marque et recommencer a faire n'importe quoi ne fois a l'aise avec leur pattern.
Ou tout simplement moins commiter (ce qui est l'inverse de ce qui est souhaite).
Le blaireau qui commite comme un porc avec "enter commit message here" dans ses commit logs, tu le prends a part, tu lui expliques, tu le forme, tu lui laisses du temps pour s'adapter. Et s'il fait toujours le con, tu recommences. Et si ca continue, tu le vires.
Sans compter que meme ceux qui savent ce qu'ils font ont plus de chances de faire une connerie avec un outil qui rend (volontairement) la tache difficile.
En regle generale, forcer les gens a utiliser un outil "parce que", c'est une mauvaise idee. Et c'est souvent (entre autre) pour eviter ca qu'on prend des solutions libres.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Interface graphique
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Interface graphique
Posté par Stibb . Évalué à 1.
Avec CVS, pas trop de soucis du moment qu'on renomme pas de fichier et que l'on applique bien un tag à chaque fois qu'on merge, mais ça aussi faut le savoir.
Et ce sont ces "faut le savoir" qui m'énervent énormément.
Pour moi, cli ou pas est la mauvaise question. Le vrai choix est :
- est ce que je veux un logiciel qui me permette de faire tout ce que je veux (en gros, le CLI), et c'est à moi de faire bien gaffe de ne pas me plante
- ou est ce que je veux que le logiciel s'occupe de la partie compliquée et ne me présente que ce que j'ai besoin pour effectuer un opération (pour moi, c'est l'intéret du GUI).
Je veux merger deux branches. J'ai leur nom. Avec un CLI, il faut que je me souvienne des options, des numéro de commit avec svn, le chemin complet vers les deux branches (tjs avec svn), etc. C'est source d'erreur.
Avec un GUI, je sélectionne juste le fichier, il m'affiche les opérations possible, je choisi, il y a moins de risque d'erreur.
J'évalue en ce moment mercurial, et effectivement il se rapproche plus de ce que je cherche que GIT. GIT est trop source d'erreur, et s'il faut passer par une surcouche de script pour l'utiliser, autant l'oublier (dans mon ancienne boite, tout le monde avait des scripts pour utiliser facilement clearcase, d'où une source d'erreur incommensurable).
Mais il faut que je trouve comment utiliser mercurial en centralisé, et c'est pas encore donné.
# Évolution
Posté par reg . Évalué à 4.
Les outils ont évolués, les besoins aussi, mais vous ne voulez pas vous adapter aux nouveaux usages.
De ce que je lis, vous voulez un fonctionnement ala papa CVS mais avec tous les bonus des VCS modernes et décentralisés.
Git ne pête jamais entre les doigts ; je vois des moyens de tout casser mais jamais au point de perdre ton boulot.
Oui, git est complexe, c'est vrai ; mais en fait il n'est pas compliqué. Il est difficile à appréhender au début car tout change, mais une fois passé l'effort d'adaptation, les actions que tu vas faire tous les jours ou toutes les semaines sont super simples et confortables. Celles que tu vas faire tous les deux mois, ben tu iras voir la doc car comme tout le monde, tu ne te souviendra pas de la syntaxe.
Pour les interfaces graphiques, moi je n'en veux pas ; c'est pas adapté à mes maigres besoins. J'utilise tig et lui trouve des limites incomfortable, mais c'est pas la mort non plus.
À mon avis, tu as plus besoin d'une bonne intégration à ton IDE que d'un nouveau VCS.
Pendant ma phase de transition ou je trouvai git stupidement complexe pour “juste” un VCS, j'aimais bien bazaar qui est un svn décentralisé intéressant.
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 4.
Sinon, les bêtises sont faciles à réparer avec git, par exemple les commits ne sont pas oubliés tout de suite et son retrouvables avec les logs qu'il crée (git reflog). C'est bien un des attraits, en plus de pouvoir faire des trucs complètement fous comme git commit --interactive pour ne commiter qu'une partie d'un fichier !
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par Christophe Fergeau . Évalué à 1.
Je me permets d'insister là dessus, ça répond au "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" du journal. Les commits qui ont été dégagés de la branche courante avec git reset --hard peuvent être retrouvés (pendant peut être 1 mois) dans le reflog.
[^] # Re: Évolution
Posté par hsyl20 (site web personnel) . Évalué à 3.
git-svn est très bien pour ça :
git svn clone --stdlayout svn://...
Travailler avec git normalement...
Pour envoyer dans le dépot svn :
git svn fetch
git svn rebase
git svn dcommit
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par pasScott pasForstall . Évalué à 0.
Donnes moi une seule raison a moitie valable pour avoir un fichier versionne qui differe du serveur sur ta box locale. A moins que tu sois un grand fan du "ca mrche sur ma machine" quand on te rapporte un bug.
S c'est versionne, tu dois avoir la version du serveur, ou la pousser le cas echeant. Tu peux vouloir tester un hack foireux, mais tu vas reverter tout ca a la fin de ta journee.
Si c'est pour de la config, ta config ne devrait pas etre versionnee, en tout cas pas les override locaux de config (sinon bonjour les catastrophes en prod).
Si tu fais du java (ce qui est probable vu que tu parles de eclipse), spring propose tout ce qu'il faut hors de la boite pour faire de la configuration par exception et mettre tes override locaux en dehors du versionnage.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 3.
Je l'utilise pour faire des commits cohérents, si par exemple j'ai fait deux choses différentes en même temps sur un même fichier, je préfère en faire deux commits.
Je fais heureusement pas de Java et je n'utilise pas Eclipse non plus. Bref, QLB.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par pasScott pasForstall . Évalué à 0.
Disons que la probabilite de faire une connerie (oublier un truc ou faire les commits dans le mauvais ordre) devient tres grande.
Ca te fait pas peur de commiter un truc qui n'a pas ete builde et verifie avant?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re:Évolution
Posté par daimrod . Évalué à 3.
soit de virer tout ce que tu as fait/faire une nouvelle branche/stasher/ bref simplement corriger le bug et commiter la correction sans la lier à ton
travail courant. git commit --interactive est là !
Et pour les commit dans le mauvais ordre ce n'est vraiment pas un problème avec git rebase --interactive.
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Si la necessite d'avoir des commits tres fins est si importante, fait le proprement, pas a la rache.
Si le patch fait une ligne, et que "c'est bon, ca se gere", ca va te prendre 30 secondes d'isoler le patch proprement.
Si c'est un truc moins trivial, tu risques fortement de faire une connerie (oubli d'une partie ou inclusion d'une autre) et au final, t'auras perdu bien plus que ce t'as gagne, d'ou l'interet de le faire proprement.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Fait une branche (tres rapide), appliques ton patch, builde, test, commit.
J'ai bien compris que ca c'etait fait pour, ca n'empeche pas que c'est tres dangereux comme feature.
Si tu peux te permettre de commiter du code non teste ni meme builde, c'est que la granularite de tes commits est pas si importante, on est donc en droit de se demander quel est l'interet de la feature?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 1.
Encore une fois on peut revenir dans l'historique avec git (et le modifier) donc non, ce n'est pas un problème, je peux tester chaque commit produit.
De plus, heureusement, un serveur va s'en occuper à ma place, car vu le nombre de tests des projets sur lesquels je travaille, je le fais de toute façon rarement en local, pas sûr que mes patrons acceptent cette excuse : http://xkcd.com/303/
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Ton commit la.
Tu l'as compile?
Tu l'as teste?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 1.
git add --interactive blabla
J'ajoute la partie de la fonction qui a été corrigée.
git commit -m "Correction d'un bug dans la fonction blibli"
Je commite ensuite mon vrai travail :
git add blabla
git commit -m "Ajout de la fonction blublu"
Je me retrouve donc avec avec deux commits. Je peux tester le précédent de manière individuelle :
git checkout mabranche^
Si j'ai envie de l'enlever ou le déplacer j'ai git rebase avec l'option… --interactive ! Décidément elle est partout.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
J'abandonne.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Indice: relit mes messages precedents tout a ete dit, ceux ui parlent de probabilite, de bonnes pratiques etc.
Si on resume "interactive, c'est de la balle"
Ouais mais c'est risque.
Non c'est de la balle.
Oui, mais c'est risque t'as vite fait de te tirer une balle dans le pied, c'est pas trop une bonne pratique.
Non c'est de la balle, t'as pas compris.
Ben ca reste risque et pas une bonne pratique.
Non, c'est de la balle, et de toutes facons, j'ai pas le temps de compiler ni de tester localement, alors bon.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
Je ne vois pas pourquoi c'est plus risqué que d'annuler la modification à la main dans son éditeur de texte (en plus d'être beaucoup plus complexe surtout si on ne peut pas annuler localement).
Tu n'as proposé aucune alternative.
En revanche, à ton premier commentaire on voit que tu n'avais pas compris pourquoi cette fonctionnalité était utilisée, mais tu as continué à la détester de façon inexplicable.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à -2.
T'as raison pankkake.
C'est bien pankkake!
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re:Évolution
Posté par daimrod . Évalué à 3.
Donc tant que tu n'as pas testé tu ne veux pas commit, j'ai bon ?
Si c'est ça c'est juste approche différente de ce que nous faisons, on commit, on test et si c'est pas bon on recommence, et vraiment le
git rebase --interactive est très sympa, tu peux fusionner des commit entre eux, rééditer un message, rebidouiller des trucs...
D'ailleurs c'est la magie du décentralisé, tu peux faire tout ce que tu veux en local, et si tu le souhaites tu ne push que les trucs qui marchent,
donc tu refais ton historique avant de le push, et en local tu gardes tous tes essais et tes erreurs.
[^] # Re: Re:Évolution
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
On te demande de nous donner une autre solution pour faire des séries de commits propres, ce qui est completement indispensable pour faire de la revue de code dans des bonnes conditions => nada.
Mais sinon, c'est nous qui sommes entêtés, hein ;-).
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Ou n'importe quoi qui ne consiste pas a modifier a la volee et a la rache du code au moment du commit.
Le truc c'est que pankkake a pas ete capable de dire autre chose que "si c'est de la balle interactive, t'es idiot" et sa solution au probleme c'est de dire "eud'facons, je teste pas localement, ca prend trop de temps", tester apres coup les commits - chose que evidemment personne ne fera, et de faire remarquer que git fournit les outils pour reparer les conneries qu'il a permit de faire en premier lieu.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
Tu es un mythomane. Tout ça parce que tu n'avais pas compris à quoi servait cette fonction au départ, et que tu es tellement atteint mentalement que tu es incapable de reconnaître t'être trompé.
C'est quoi ta solution, attendre une dizaine de minutes entre chaque commit ?
Enfin, tu crée un faux problème car voici mon utilisation première : https://linuxfr.org/comments/1206237.html#1206237
« chose que evidemment personne ne fera »
Il y a une machine qui le fait à ma place automatiquement. Je n'ai juste pas envie d'attendre une dizaine de minutes entre chaque commit.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à -2.
Tu es un mythomane. Tout ça parce que tu n'avais pas compris à quoi servait cette fonction au départ, et que tu es tellement atteint mentalement que tu es incapable de reconnaître t'être trompé.
Ben voyons!!!
J'ai tres bien compris a quoi sert cette fonction, a faire des patchs a la rache au moment du commit, c'est bien ca mon probleme avec. Tu trouves ca propre de pousser des commits comme ca, c'est cool pour toi, j'espere juste que ca pas toi qui ecrit la charte qualite dans ta boite.
Et pour quelqu'un qui pretend ne pas avoir le temps de tester en local, pretendre que tu vas verifier chacun de tes commits avant de faire un push, laisse moi rigoler et douter largement.
Il y a une machine qui le fait à ma place automatiquement. Je n'ai juste pas envie d'attendre une dizaine de minutes entre chaque commit.
Ta machine, elle va builder tous les commits independament? Non, elle va prendre un commit, attendre 15-20 minutes au cas ou un autre suive et va lancer un build sur le resultat final. Ton patch a la rache au milieu, il est potentiellement pete, t'en sais rien, et le seul moment ou tu le sauras, c'est quand ca aura pete qq part down the line.
Apres venant de quelqu'un qui pretend qu'un telechargement centralise scale mieux qu'une distribution par bittorrent, tres honnetement, plus rien ne m'etonne...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
Évidemment, oui.
Et non, tu n'avais pas compris, cf. https://linuxfr.org/comments/1205889.html#1205889
Pour le reste, je t'ai déjà répondu, si tu n'es pas content il fallait répondre à ce moment là plutôt que de les sorties pitoyables qui sont à ton habitude : https://linuxfr.org/comments/1205914.html#1205914 plutôt que revenir quelques jours après pour crier victoire en espérant que la personne qui a essayé de te faire comprendre quelque chose ne te lit plus à ce moment là. C'est une technique déplorable, pitoyable, qui ne convainc que toi.
Tu es un pauvre raté mythomane, et je n'ai plus envie de nourrir tes troubles psychiatriques. Tu montres bien là qu'il est impossible de discuter avec toi, tu es une machine enrayée.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à -1.
Merci pour la barre de rire.
Fait gaffe quand meme, je me suis fait supprimer des commentaires pour moins que ca.
Mais alors, bittorrent, c'est centralise? Et ca scale moins bien que 10 000 clients qui telechargent 400Mo en meme temps?
Et tu m'as toujours pas explique comment distribuer 4To en 15 secondes de facon centralisee.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par DLFP est mort . Évalué à 2.
Merci pour la barre de rire.
Fait gaffe quand meme, je me suis fait supprimer des commentaires pour moins que ca.
Difficile de faire plus minable comme sortie, et pourtant tu en es le spécialiste. Comme quoi, j'ai touché juste : va te faire soigner, c'est urgent.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Re:Évolution
Posté par pasScott pasForstall . Évalué à 0.
Reponds d'abord a mes questions sur murder par exemple. Tout ce que t'as fait jusqu'a present c'est pretendre que bit torrent scale moins bien qu'un telechargement centralise et essayer de faire passer qq To sur une connexion gigabit et disant "meuh si, ca passe bien".
Note que j'attends pas grand chose de concret, je commence a te connaitre.
Apres t'auras gagne le droit de m'insulter.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Re:Évolution
Posté par Moonz . Évalué à 4.
git add --interactive
git ci -m "petit fix à l’arrache"
git stash
./tests/run
git stash pop
[^] # Re: Re:Évolution
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Re:Évolution
Posté par Antoine . Évalué à 0.
soit de virer tout ce que tu as fait/faire une nouvelle branche/stasher
Ou alors "$VCS di > montravail.patch" suivi de "$VCS revert" pour bosser sur le petit bugfix avant de revenir au travail d'origine. Pas besoin de sortir l'artillerie lourde et le dernier plugin du petit frère de Jean-Linus qui déchire ton repo avec des merges de multicéphalopode et anti-aliasing 4x.
(les commandes ne marcheront probablement pas sous git mais ça vous apprendra à faire les malins avec votre cli pourrie :-))
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 3.
Je vois pas le rapport, tout va être commité, et je peux toujours tester chacun des deux commits si j'en ai vraiment envie.
L'alternative c'est de faire un commit qui dit « j'ai fait ça ET ça », et c'est horrible pour au moins deux raisons : ça rend l'historique plus difficile à lire, et si ce commit introduit une régression, il est aussi associé à autre chose sans raison.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par pasScott pasForstall . Évalué à 1.
Mais si ton commit fait trois lignes, t'as pas besoin de interactive pour isoler le patch...
Si ton commit est moins trivial, t'augmentes fortement la probabilite de faire une connerie. Au final tu te retrouves dans le deuxieme cas (commit melanges), sauf que c'est pas volontaire, que le premier commit ne va meme pas compiler et ca va foutre la merde encore plus.
Je veux bien croire que la plupart du temps, ca marchera tres bien, mais c'est loin d'etre une bonne pratique.
Si t'as tant besoin que ca d'avoir des commits independants, commit de maniere independante en verifiant tes commits, si c'est pas si important, mets tout ensemble plutot que de faire 2 commits dont le premier est potentiellement pas correct du tout.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 3.
C'est tout autant source d'erreur, c'est même plus difficile et plus long.
Tu ne serais pas contre cette fonctionnalité juste parce que tu ne l'as pas comprise / ne l'as pas dans le gestionnaire de version de ton choix ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par pasScott pasForstall . Évalué à 0.
A priori:
- branche fraiche a partir du dernier commit,
- application du patch,
- build, test, maintenant ou plus tard, tu t'en fout, c'est isole. Apres, c'est bien ca l'interet des dvcs, non? Rendre les branches tellement cheap que tu peux en faire une en 2 secondes et l'integrer plus tard si tu veux.
Ca va te prendre environ 30 secondes pour les 2 premieres etapes.
Sauf si ton patch est pas trivial, mais s'il est pas trivial faut avoir de grosses couilles pour le commiter en aveugle au milieu d'un autre patch, non?
Ou alors, c'est que la granularite si fine est pas necessaire, que tout ce qui compte c'est le build a la fin de la journee, mais alors pourquoi tu t'emmerdes avec tout ca?
Si tu tiens a faire du quick and dirty et commiter la main'nant toussuite, tu peux faire le grouick avec un buffer texte, copier le fichier courant, reverter
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par Moonz . Évalué à 4.
[^] # Re: Évolution
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Évolution
Posté par Christophe Fergeau . Évalué à 1.
git reset --hard avec des changements non committés (en particulier des changements dans l'index/un nouveau fichier non committé dans l'index),
git clean -dfx avec un nouveau fichier source que tu as oublié d'ajouter et de committer, ...
J'invente pas hein, c'est des choses qui me sont arrivées ;) Heureusement git encourage à committer souvent donc les pertes n'étaient pas énormes
[^] # Re: Évolution
Posté par Moonz . Évalué à 4.
Absolument tout SCM a une commande similaire, c’est pas du tout spécifique à git ça. Sous SVN, c’est svn revert.
> git clean -dfx avec un nouveau fichier source que tu as oublié d'ajouter et de committer, ...
Idem, tous les SCM que je connais ont une fonctionnalité similaire.
[^] # Re: Évolution
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Par contre, quand Christophe a écrit "git reset --hard", il voulait probablement écrire "git stash", et là, la supériorité de Git (ou d'à peu près n'importe quel outil en fait) sur SVN est criante ...
http://stackoverflow.com/questions/1554278/temporarily-put-a(...)
[^] # Re: Évolution
Posté par Christophe Fergeau . Évalué à 2.
[^] # Re: Évolution
Posté par beagf (site web personnel) . Évalué à 3.
Tu prend n'importe quel outil, si tu fais des modif locales pas encore envoyées sur le serveur, un simple "rm -rf ." à la racine du projet va foutre le bordel.
Donc avant de faire un "rm -rf" tu réfléchi parce que tu sais que c'est super dangereux, et bien dans GIT, faire un "reset --hard" c'est la même chose, tu sais que c'est potentiellement dangereux, donc tu réfléchis un minimum et tu essayes de prendre de bonnes habitudes du style utiliser plutôt le stash.
Si tu perd quelque chose avec la commande "reset --hard" c'est uniquement de ta faute et tu devrais dire merci à GIT de t'apprendre à la dure que l'on fait attention :
- le nom de la commande en lui même te préviens que c'est dangereux ;
- il y a d'autres façons plus sécurisées de faire quasiment tout ce que fais cette commande ;
- après un hard tu peut encore retrouver tes comits si tu n'a pas fais le con.
Donc si tes données son réellement perdues, c'est de ta faute et pas celle de GIT de la même manière que quand tu fais un "rm -rf".
# Ce qui te manque: des alias et un workflow défini
Posté par Aissen . Évalué à 3.
Mais il existe des alternatives proprios avec suffisament de valeur ajoutée, par exemple SmartGit, ou Github pour l’hébergement.
Maintenant par rapport à tes griefs sur git, des alias(fonctions bash) non testées:
checkin (){
git commit $@
git fetch
git rebase origin/master
git push
}
pushbranch(){
git push origin $1:refs/heads/$1
}
J’ai supposé que la source était origin/master (comportement par défaut en tout-centralisé).
Pour l’historique: voir git revert
En général remplacer l’historique c’est mal, très mal. Mais c’est possible:
replacemasterwithversion(){
git branch -M master old-master-`date +%s`
git checkout -b master $1
git push -f # pas bien !!!!!!!!!!
}
Pour l’interface graphique, voire smartgit. Je ne suis pas convaincu que ça soit nécessaire.
Pour le reste, voir le commentaire de reg: https://linuxfr.org/comments/1204997.html#1204997
[^] # Re: Ce qui te manque: des alias et un workflow défini
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Ce qui te manque: des alias et un workflow défini
Posté par Aissen . Évalué à 1.
Par contre, je crois pas que l’on puisse faire ce que je présente plus haut, c’est à dire manipuler les arguments de manière un peu plus complexe, comme ce que j’ai proposé dans les fonctions bash plus haut (et pas des alias bash justement, qui ont la même limitation).
[^] # Re: Ce qui te manque: des alias et un workflow défini
Posté par Aissen . Évalué à 1.
http://davidwalsh.name/git-aliases
Mais ce n’est pas documenté dans le man…
http://www.kernel.org/pub/software/scm/git/docs/git-config.h(...)
[^] # Re: Ce qui te manque: des alias et un workflow défini
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
# Quelques éléments
Posté par El Titi . Évalué à 6.
J'ajouterai 2 outsiders que sont Bazaar et Mercurial et j'ignorerai CVS
Ton workflow:
- 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.
Tous les VCS supportent ton workflow à priori mais SVN a quelques limitations.
Il ne supporte pas les merges cycliques comme ca:
B T
|<-|
|->|
|<-|
|->|
Dans ton cas tu ne merges que dans un sens (release vers mailine) et au pire une fois dan l'autre sens pour réintegrer un bugfix:
|<-|
|<-|
|<-|
|->|
Avec SVN le dernier merge se fait avec l'option réintégrate et la branche doit être killée.
Autre limitation, si tu branche une fois tu ne dois JAMAIS refaire un cp entre les 2 branches depuis un sous-répertoire sous peine de faire mumuse avec les mergeinfo
Enfin bon courage pour suivre un changeset losrque tu a fait un mv :
http://linuxfr.org/comments/1204996.html#1204996
Centralisé
======
A vérifier mais hormis les VCS purement centralisés, le seul DVCS qui supporte ce mode est Bazaar
Par centralisé, j'entends le fait de pouvoir commiter directement dans la branche centrale sur un serveur et si une version concurrente sur cette branche a été commitée, tu en es empêché jusqu'à ce que tu résolves le conflit et que tu retentes ta chance (schema de concurrence optimiste)
Pour les autres (Hg et Git) c'est un peu différent mais il faut comprendre qu'on y arrive très bien sinon il ne serait pas possible de faire de l'intégration continue avec les DVCS.
Le principe est qu'on travaille dans sa propre branche et que par defaut le commit distant est séparé en 2 étapes: 1 commit local + 1 push.
Il est toujours possible d'enchaîner ces 2 étapes en une même transaction et c'est au niveau du serveur (au moment du push) qu'est géré le fait d'accepter ou non le changeset car il n'y pas d'édition concurrente.
Avec Git, on a des vraies branches, le push est refusé si le changement que tu commites n'est pas une feuille (l'ancêtre de ton changement a déjà un autre fils) auquel cas tu dois resoudre le conflit (equivalnt du svn resolve) dans ta branche et retenter.
Avec Hg c'est un peu comme monotone. Les branches ne sont qu'une commodité et un noeud peut avoir plusieurs fils sans pb.
Par défaut, tu peux toujours commiter ou pusher (à vérifier) même si tu as plusieurs heads. Tu as une commande qui détecte le fait que tu as plusieurs
Si tu veux bloquer, il faut installer un hook sur le serveur (je crois).
Ce qu'il faut retenir c'est que le commit local est quand même un avantage lorsque tu es déconnecté et que tu veux par exemple prendre en charge plusieurs bugs request à la suite et les commiter séparément (merge par la suite) et c'est aussi transparent qu'un VCS centralisé si tu associes commit+push en une seule commande.
En revanche ce que ne permettent pas les DVCS c'est le lock pessimiste (le checkout reserved ala Clearcase puisque tu connais)
Ceci peut parfois s'avérer utile pour les utilisateurs qui ont des besoins très limité ou lorsque les fichiers traités sont inadaptés pour les merges. (modèles UML fragmentés dans Eclipse par exemple)
Avec SVN, tu t'en sors en placant les fichiers en lecture seule et avec une propertie svn:needs-lock.
Bon je poursuis dans un autre post.
[^] # Re: Quelques éléments
Posté par pasScott pasForstall . Évalué à 1.
Meme sans etre deconnecte.
Ca permet de commiter comme un boeuf toute la journee et d'avoir des changesets a la granularite tres fine, sans pour autant forcer tout le monde a faire un checkout toutes les 15 minutes pour etre sur de pas etre en conflit, ou lancer 35 builds par jour sur hudson.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Suite
Posté par El Titi . Évalué à 4.
=============
La je crois qu'il n'y a pas trop de pb de ce coté avec les outsiders
Intégration dans eclipse
===============
HGE (pour Hg) est à ma connaisance assez abouti et son dev est maintnat soutenu par CodeBeamer un editeur de bug tracker.
Le plugin pour Bazaar est à chier.
Par contre tu parles de Windows (Visual Studio) et cc'ets un peu ma crainte aves GIT.
Au niveu du CLI rien de consistant.
On a d'un coté msygit en natif et de l'autre une réimplementation en Java JGit avec un CLI balbutiant et un plugin Egit basé dessus.
Qu'est-ce qui se passe quand le format de stockage évolue. Sont-ils compatibles à 100% en attaquant le même dépôt
Hg me parait plus consistant avec un seul backend quelque soit l'OS.
Hg a aussi un "command set" beaucoup plus simple à appréhender.
Enfin, je ne parlerai pas de la possibilité de customiser Git sous Windows (à coup de cygwin c'est quand même un peu gruik)
Avec Hg tu peux ecrire tes plugins et tes hooks en python plutôt que d'appeler des suprocess ou des scripts. J'imagine qu'il doit y avoir une API C à Git mais existe t'elle sous Windows. Peut-être que l'API EGit est suffisante.
L'historique
=========
Ta demande est un peu confuse
A un moment on a l'impression, que c'est l'arbre de version Clearcase (par fichier) qui te manque puis le browsing des sources distant via ton navigateur
et après en local dans Eclipse.
En quoi le fait que le browsing local est un pb ? Tu n'as qu'a updater et en plus c'est beaucoup plus rapide.
Si tu le fais à distance tu passes par ton navigateur (avec HG tu as d'ailleurs un mini serveur web qui te permet de browser n'importe quel clone)
Il existe peut-être des plugins qui pemettent de browser dans Eclipse un repository distant mas je ne vois pas l'intérêt. (sauf peut-être ne pas être polluer par les branches locales de Git)
[^] # Re: Suite
Posté par Stibb . Évalué à 1.
Alors je vais rebondir :
- Visual Studio, Xemac, Vim : c'est pas pour moi, mais c'est pour que l'on me dise "ah oui, je peux utiliser ton GIT facilement sur mon environnement". Encore une fois, ici le fait de faire une branche fais tres peur. Alors, il me faut qque chose de simple et efficace.
- ClearCase avait son horreur de config spec, mais une chose est sur : les merge étaient simple. Tu prends une branche et tu merges sur une autre. Bon, on perdait bcp de temps mais ça se passait bien.
- l'historique : en fait, je veux l'arbre de version de GIt que je trouve parfais, MAIS sans qu'il bouge dans tous les sens dès qu'on checkout une anciene version. J'utilise énormément les options compare d'éclipse, pour comparer un dossier ou un fichier par rapport à une ancienne version. Avec CVS c'est royal pour un fichier, on choisi la branche. Avec SVN il faut se battre avec le numéro de commit (tres bien, pas de soucis) ou le chemin vers la branche. Moi ca m'énerve ca.
- oui je peux accepter un historique par un browser, genre repository viewer.
J'ai testé intensivement ce week end mercurial, et il me convient plutot bien. Je dois avouer que tortoiseHg me plait beaucoup, et en utilisant un trigger "push after commit", le comportement se rapproche d'un CVS/SVN. Néanmoins je vois deux gros problemes:
1) je n'arrive pas à créer une branche à la fois en local et à la fois en remote, il me pose une erreur lors du push.
- Si je développe en local et qu'il y a un conflit, au lieu de me dire "il y a un conflit, faite un update + corriger le conflict", il me créé une branche sur le repository central et c'est au maintainer de merger les 2 branches. Je veux un fonctionnement sans maintainer au niveau du repository central...
G.
[^] # Re: Suite
Posté par El Titi . Évalué à 2.
Déjà quels hook utilises-tu, un truc comme ça ?
http://stackoverflow.com/questions/1235597/mercurial-automat(...)
Si je développe en local et qu'il y a un conflit, au lieu de me dire "il y a un conflit, faite un update + corriger le conflict", il me créé une branche sur le repository central et c'est au maintainer de merger les 2 branches. Je veux un fonctionnement sans maintainer au niveau du repository central...
Normalement il proteste quand tu essaies de pusher alors qu'il y aune autre head et te demande d'updater et merger. C'est ce que tu attends non ?
Moi j'ai bien un message:
"""
pushing to ..\repo1
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
"""
Sinon, quel est ton problème avec la création de branche ?
Quel message lors du push ?
Si tu crées une branche, il faut la créer une fois et la pusher.
Il faut pas la recréer sur le clone distant.
[^] # Re: Suite
Posté par Stibb . Évalué à 1.
En effet, en utilisant mercurialeclipse avec le hook suivant, j'ai bien le comportement attendu (les branches sont commité proprement, les merges sont simples et le repo central a toujours le bon état, comme un repo svn/cvs). Je suppose que mercurialeclipse fait des commit --force.
Le hook utilisé qui marche bien est le suivant :
[hooks]
commit = hg push
Par contre, ce que je n'ai pas:
- "compare with" / "replace with". J'utilise ça énormément, pour vérifier que je vais commiter un bon code, visualiser les changements de la version actuelle avec telle ou telle version. etc. Pareil dans l'historique, je n'ai pas "compare current rev with this version".
- je suis obligé de modifier le .hg/hgrc à chaque fois que je fais un clone, il n'y a pas moyen de mettre une fois pour toute le "hook" qui soit automatiquement appliqué dès que qqu'un fait un clone ?
- quel est le hook à utiliser pour toujours faire un "commit --force" ?
- est ce qu'il est possible de renommer la branche principale ("default" => "mainline ou trunk") ?
[^] # Re: Suite
Posté par El Titi . Évalué à 2.
http://www.javaforge.com/project/HGE
L'history view te permet ça et le compare with previous existe depuis la 1.5
http://blogs.intland.com/main/entry/48
Pour le hgrc, ca ne devrait être le cas si tu le place dans ton profil Windows non ?
http://www.selenic.com/mercurial/hgrc.5.html
Les hooks ne sont pas répliqués pour des raison de sécurité
http://hgbook.red-bean.com/read/handling-repository-events-w(...)
Tu devrais y être habitué avec les triggers coté client de CC
Les solutions sont donc spécifiques à ta boite (montage NFS, scripts de synchro a démarrage, un .hgrc à récupérer sur un site, un packaging d'install customisé, ...)
Y'a pas de solution miracle.
L'avantage est que tu peux mettre aussi des hooks coté serveurs et il faut bien différencier ceux que tu veux déployer et ceux que tu veux sur ton repository central.
commit --force ???
Y'a pas d'option --force, tu peux toujours commiter dans ton clone
est ce qu'il est possible de renommer la branche principale ("default" => "mainline ou trunk") ?
Je crois pas mais je vois pas où est le pb.
[^] # Re: Suite
Posté par Stibb . Évalué à 1.
Mais je trouve ça tres stupide de ne pas avoir un fichier de conf qui se déploie lors d'un clone, comme git. Meme si ca ne déploi pas de hook qui peuvent etre dangeureux effectivement, je veux juste des options par défaut.
Par exemple, le --force est pour push (et non pas commit, dsl). Je dois faire "hg --force --new-branch" pour être sur que tout ce passe bien. Il y a un moyen de configure mon hgrc pour qu'il fasse ça tout seul automatiquement?
J'utilise mercurialeclipse 1.7 (qui est donc postérieur à hgeclipse 1.5), et je n'ai pas de "compare with" pour les dossiers. Pour un fichier donné, effectivement, j'ai accès à ces options, mais ce que je veux, évidement, c'est un diff depuis la racine du projet (et pas uniquement fichier par fichier).
[^] # Re: Suite
Posté par El Titi . Évalué à 2.
Mais je trouve ça tres stupide de ne pas avoir un fichier de conf qui se déploie lors d'un clone, comme git. Meme si ca ne déploi pas de hook qui peuvent etre dangeureux effectivement, je veux juste des options par défaut.
Tu dois pouvoir te débrouiller en ajoutant un .hgrc dans ton depôt et en faisant
un truc du genre %include $(hg root)/.hgrc dans ton fichier .hgrc par défaut (vaudrait mieux sécuriser le truc pour checker la provenance du clone)
Comme ça chaque projet centralise ses préférences.
Ca marche un peu comme les inclusions de makefile.
Par exemple, le --force est pour push (et non pas commit, dsl). Je dois faire "hg --force --new-branch" pour être sur que tout ce passe bien. Il y a un moyen de configure mon hgrc pour qu'il fasse ça tout seul automatiquement?
Je comprend toujours pas pourquoi tu veux forcer le push dans une nouvelle branche si tu veux un comportement à la SVN.
Dans SVN ton commit est refusé si quelqu'un d'autre a commité entretemps et tu dois résoudre avant de resoumettre. Ici par défaut sans --force ca fonctionne comme ca pour peu que tu aies positionné:
commit.autopush= hg push
J'utilise mercurialeclipse 1.7 (qui est donc postérieur à hgeclipse 1.5), et je n'ai pas de "compare with" pour les dossiers. Pour un fichier donné, effectivement, j'ai accès à ces options, mais ce que je veux, évidement, c'est un diff depuis la racine du projet (et pas uniquement fichier par fichier).
Là je ne peux pas te répondre, car je ne connais pas assez le plugin eclipse
mais la synchronisation view devrait suffire la plupart du temps non ?
http://www.javaforge.com/wiki/76412#section-Synchronization+(...)
Au lieu de te donner l'arbo complète, tu browses le changeset de manière hiérarchique.
Une bonne âme qui passe par ici pourra peut-être t'aider (au hasard pff ?)
[^] # Re: Suite
Posté par Stibb . Évalué à 1.
http://www.javaforge.com/issue/12120
Avec mercurialeclipse, le comportement est très bien : il m'indique qu'il y aune erreur, et je dois me débrouiller pour les passer en resolve. Parfait.J'aimerais trouvé une configuration qui fasse que ceux qui ne l'utiliseront pas (genre ceux qui utilisent tortoisehg/hgtk) ait le meme comportement. Apparement, l'option force empeche de faire un merge, et new branch créé une branch si un merge est nécessaire.
Je reviendrais peut etre par ici avec un hgrc bien léché.
[^] # Re: Suite
Posté par El Titi . Évalué à 2.
Pour la propagation des configs, voici un thread qui propose la même chose (celui qui est noté 2) avec les mêmes risques.
http://stackoverflow.com/questions/856523/version-controlled(...)
J'aimerais trouvé une configuration qui fasse que ceux qui ne l'utiliseront pas (genre ceux qui utilisent tortoisehg/hgtk) ait le meme comportement. Apparement, l'option force empeche de faire un merge, et new branch créé une branch si un merge est nécessaire.
C'est ca que je t'explique, c'est valable par défaut. (cf.ma sortie d'écran)
Le push est refusé et le resolve est fait dans ton clone (comme dans ton workspace SVN). Pourquoi créer une branche ?
Au contraire, le -force pushe une version concurrente (et le new branch créé une nouvelle branche qui pollue ton repo (c'est juste un nom sur ta revision en fait)
Si tu veux "vraiment" (mode paranoiaque) te prémunir contre le -f, il te suffit d'installer un hook coté serveur.
http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_pu(...)
[^] # Re: Suite
Posté par Antoine . Évalué à 3.
Bien sûr. Ajoute la section suivante dans ton hgrc :
[defaults]
push = --force --new-branch
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: easygit
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
J'ai fait du support à des étudiants en projet (50 équipes de 4 étudiants, à plein temps pendant 1 mois) avec SVN, et avec Git depuis 2 ans. Contrairement à ce qu'on aurait pu croire, j'ai moins de problèmes à résoudre depuis qu'on est passés à Git.
Ce qui est clair, c'est que la migration SVN -> Git est douloureuse (au moins pour les non-geek), mais pour l'apprentissage à partir de zero, mon expérience est que ça n'est pas pire.
[^] # Re: easygit
Posté par Philippe F (site web personnel) . Évalué à 3.
Au passage, tous les outils de commits devraient avoir la convivialité de TortoiseHG. Ceux qui disent que la ligne de commande en un hg/svn/git diff + un éditeur suffisent pour savoir tout ce que tu as modifié ne savant pas ce qu'ils perdent.
# Bazaar
Posté par jijijaco . Évalué à 1.
Il existe également une interface graphique (mais la traduction française est très mauvaise).
Il me semble que bazaar rempli à peu près tous les critères que tu recherches.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.