Bonjour
Je travaille beaucoup avec SVN et CVS sous linux, essentiellement avec eclipse. J'aimerais beaucoup passer à un vrai gestionnaire de version. J'ai déjà utilisé GIT sur des projets, et j'adore énormément, néanmoins, l'omniprésence de la ligne de commande me gène beaucoup. Je suis un adepte du concept "une GUI pour les dominer tous". Une GUI bien léchée pour moi est avant tout le moyen le plus efficace et surtout de ne pas commettre d'erreur.
Merci de ne pas tomber dans le troll "mais la ligne de commande est plus efficace pour les 12000 raisons suivantes". Je ne VEUX pas de ligne de commande, je veux un outils "tu cliques tu pointes". La gestion de conf doit etre le plus simple, efficace et transparent pour moi.
Mercurial, je connais pas, mais j'ai l'impression qu'au niveau fonctionnel on est à peu près au même niveau que GIT (bon, le stash/index manque, peut etre 2 3 autres fonctions sympathiques, n'empeche que l'essentiel est là).
Et l'essentiel pour moi c'est:
- brancher, merger, etc de manière transparente dans mon travail. Un bouton pour commiter, une boite de dialogue pour remplir le log, un historique pour regarder les version, un outil de comparaison pour vérifier les changement, et un outil de merge automatique, voilà tout ce qu'il me faut
- j'ai vraiment beaucoup beaucoup de mal avec gitk ou git gui. En théorie oui ca marche, mais dans la pratique, je n'arrive pas à l'utiliser. La vue en historique est limitée à la branche actuelle par défaut (c'est stupide, s'il y a plusieurs branche, j'ai besoin de toute les voir, s'il y en a trop, on peut afficher que les dernières actives,...). J'utiliserais bien qgit, mais pareil, il manque des outils de merge efficace.
De manière générale, je trouve que tous les GUI se ressemblent, mais aucun ne propose de faire le boulot comme il faut. A chaque fois je me dit "bon, très bien, je vois l'historique, mais comment je sors cette version particulière", ou "je voudrais tagger cette version ou créer une branche à partir de là, comment je fais?" ou (le plus souvent) "comment je merge?". Bref, aucun ne me semble suffisament mur pour ne pas retomber sur la ligne de commande. Que ces outils utilisent la ligne de commande en interne ne me dérange pas, mais je ne VEUX pas avoir affaire à cette bestiol là. Je l'utilise assez souvent pour me dire que plus je m'en passe, mieux je me porte.
Eclipse avec son projet "egit" me semble très prometteur. Ces développeurs là on compris qu'un outil doit être le plus intégré possible. Mais l'outil git ne sera pas mur avant l'année prochaine (pas d'historique, pas d'outil de merge pour l'instant). Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant. Pour SVN, avec collabnet merge utility on peut merger des branches SVN, c'est pas mal tu tout, mais il faut choisir les commits sur la branche à commiter (mon repo est en SVN < 1.4). Moi ce que je veux c'est "prend cette branche et applique là sur le trunk". Point bar.
Le but a terme est de convertir des collegues de bureau pour qui la notion de branche est déjà source d'erreur possible, ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.
Donc, voilà, dans l'état actuel des connaissances, est ce que GIT ou Mercurial sont "murs" pour mes cas d'utilisation?
Merci pour vos remarques!
# Git…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
[^] # Re: Git…
Posté par blobmaster . Évalué à 5.
j'utilise hgtk qui est très bien et qui est plus ou moins lié à tortoise (je sais pas à quel point) => iIHM unifiée sous Windows et sous Linux ce qui est bien pour du dev multiplateforme.
# gitk --all
Posté par Thomas Petazzoni (site web personnel) . Évalué à 5.
[^] # Re: gitk --all
Posté par Stibb . Évalué à -6.
[^] # Re: gitk --all
Posté par grochon . Évalué à 3.
Tu te fais un p'tit .desktop qui lance gitk --all au lieu de gitk.
Mais arg! éditeur de text /o\
[^] # Re: gitk --all
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ou alors, tu regardes dans le menu « View » de gitk, tu trouves « New view », et tu cherches la/les cases à cocher qui vont bien.
Je connaissais gitk --all, mais pas leurs équivalents graphiques, il m'a fallu plus de temps pour rédiger ce message que pour trouver les options. Bref, l'auteur du journal n'avais pas très envie de trouver visiblement.
[^] # Re: gitk --all
Posté par Stibb . Évalué à 1.
Et gitk/git gui sont pas mal pour faire du commit simple, mais dès que tu veux aller un peu plus loin tu retombes dans la ligne de commande.
Et surtout, une interface graphique avec des bouton et des champs partout n'a aucun intéret par rapport à la ligne de commande. Il faut une interface propre, orientée processessus (quand je pars dans une session de merge, je ne veux pas voir tout ce qui concerne la création de tag).
# Sans lever le troll ...
Posté par totof2000 . Évalué à 4.
sans lever le troll : tu commets une grave erreur. Je n'ai rien contre les GUi lorsqu'ils sont utilisés à bon escient. Il y a de nombreux cas ou utiliser un GUi n'apporte rien, et est contre productif. Maintenant si tu préfères un GUI dans ce cas, je ne te jugerai pas, mais sache que dans de nombreux cas un GUI ne sert à rien.
De manière générale, je trouve que tous les GUI se ressemblent, mais aucun ne propose de faire le boulot comme il faut.
Passe en ligne de commande ... :)
Sinon à mon avis, Git et Mercurial sont fonctionnellement très proches. Cependant il me semble que Mercurial est plus avancé dans la gestion des dépots via http/https : ça ressemble plus à SVN de ce côté. Avec git je ne pense pas qu'on puisse utiliser HTTP/HTTPS pour envoyer les modifs d'un dépot local vers un dépot distant (ou alors il y a une bidouille).
[^] # Re: Sans lever le troll ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Exact, mais qu'est-ce que ça apporte au juste ?
Git a deux modes de transmission principaux : la publication en lecture seule via son protocole natif, et l'envoi via SSH.
Avec git je ne pense pas qu'on puisse utiliser HTTP/HTTPS pour envoyer les modifs d'un dépot local vers un dépot distant (ou alors il y a une bidouille).
Si, ça se fait très bien, mais ce n'est pas super bien intégré. Le transport HTTP de Git est clairement un palliatif quand on ne peut utiliser ni le protocole natif, ni SSH.
[^] # Re: Sans lever le troll ...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Plus récemment, Git a appris un protocole « smart HTTP », comme ce que Mercurial savait faire depuis longtemps : un protocole spécifique à Git (avec script CGI côté serveur) plus efficace. Le principal intérêt par rapport à SSH étant d'être plus firefall/proxy-friendly.
Mercurial a eu de l'avance sur ce point, mais je ne pense pas qu'il reste de différence notable aujourd'hui.
[^] # Re: Sans lever le troll ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Pas friendly. Au contraire, le but est de contourner les pare-feux.
[^] # Re: Sans lever le troll ...
Posté par totof2000 . Évalué à 2.
Si, ça se fait très bien, mais ce n'est pas super bien intégré. Le transport HTTP de Git est clairement un palliatif quand on ne peut utiliser ni le protocole natif, ni SSH.
Ca arrive plus souvent qu'on ne le croit.
[^] # Moi aussi je veux sauver les trolls qu'on essaye de tuer dans l'œuf
Posté par calandoa . Évalué à 2.
Ben oui, mais il y a aussi de nombreux cas ou les GUI sont bien plus productives... et justement il se trouve que c'est particulièrement le cas avec CVS ou SVN. Utiliser par ex. Tortoise avec un outil de diff graphique est sans le commencement du début du millième d'une comparaison possibe avec des outils en ligne de commande exclusivement. « N'avoir rien contre » n'est pas suffisant. Il faut savoir reconnaître leur absolue supériorité dans ces cas là.
[^] # Re: Moi aussi je veux sauver les trolls qu'on essaye de tuer dans l'œuf
Posté par totof2000 . Évalué à 3.
Tu as mis les mots qu'il fait : dans ces cas là, et je sui prêt à reconnairtre eur supériorité si c'est le cas (mais je ne l'utilise pas pour le moment dans ces cas la ).
[^] # Re: Moi aussi je veux sauver les trolls qu'on essaye de tuer dans l'œuf
Posté par totof2000 . Évalué à 0.
[^] # Re: Moi aussi je veux sauver les trolls qu'on essaye de tuer dans l'œuf
Posté par calandoa . Évalué à 2.
# plop
Posté par CrEv (site web personnel) . Évalué à 2.
oué, enfin sauf les branches locales nommées sous git qui n'existent pas sous mercurial (oui je sais, il y a des extensions mais j'ai jamais retrouvé ce qu'il y a sous git)
Sinon, pour la GUI : le problème c'est que les cas sont nombreux, complexes, donc pour faire un gui propre et complète pour git / mercurial c'est compliqué. Si on rajoute en plus le support d'extensions (dont certains sont indispensables, comme stgit) ça devient le bordel.
Donc, peut-être qu'un jour egit sera potable, pour le moment il ne sert pas à grand chose...
> Pour l'instant, j'utilise CVS donc c'est assez limité, mais suffisant
toutes mes condoléances
> mon repo est en SVN < 1.4
si en plus tu t'amuse avec des trucs obsolètes ;)
> ils sont habitué à un développement très linéaire (on commit tous dans la HEAD, yohooo!!!) il faut que je le sorte un "workflow", simple, efficace, fonctionnel, et surtout, sans source d'erreur.
ouch !
heu ...
bon courage ;)
Je bosse avec svn + git-svn, autour de moi on a du svn, des branches ... ben c'est déjà pas évident d'envisager une migration git (essentiellement pour les raisons de GUI) donc si les dev n'utilisent pas du tout les branches, c'est po gagné (mais si ça marche je veux bien la recette ;))
As-tu regardé du côté de bazaar ? Les perfs sont assez désastreuses, mais c'est assez bien foutu et pour une migration cvs/svn vers un dcvs c'est très intéressant.
Quelques liens pour compléter (et pour relever le niveau de mon message...) :
- Bazaar workflows [http://wiki.bazaar.canonical.com/Workflows]
- A successful git branching model [http://nvie.com/git-model]
- a guide to branching in mercurial [http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)]
- mercurial workflows: branch as needed [http://stevelosh.com/blog/2010/02/mercurial-workflows-branch(...)]
- mercurial workflows: stable & default [http://stevelosh.com/blog/2010/05/mercurial-workflows-stable(...)]
-bonus : [http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/]
[^] # Re: plop
Posté par Dring . Évalué à 1.
Dans mon cas, on bosse sur un serveur de base de données propriétaire. Comme les coûts de licence sont élevés, tous les développements se font sur la même base, avec comme conséquences :
1) la base qui est régulièrement cassée par un nouveau développement en cours de test
2) le besoin de se synchroniser très souvent sur une base commune à tous
Du coup, créer des branches de dev ne nous serait d'aucune utilité.
[^] # Re: plop
Posté par Stibb . Évalué à 2.
Trunk => doit toujours compiler.
Mes petites branches de dev ne me genent pas, mais avec CVS ou SVN, impossible de renommer un fichier en gardant l'historique. Innadmissible.
Cela dit, SVN est pas mal, surtout intégré avec trac. Mais la gestion des dossiers est calamiteuse et les tags ne sont pas de vrai tag sans des hook à la c...
[^] # Re: plop
Posté par Albert_ . Évalué à 1.
git aussi et je crois que pour mercurial c'est pareil.
[^] # Re: plop
Posté par Dring . Évalué à 2.
D'où ma remarque sur : "créer des branches de dev n'est pas toujours utile/adapté".
Sinon, aux dernières nouvelles SVN sait renommer un fichier en gardant l'historique, non ? C'est une des raisons pour lesquelles il a été développé, en remplaçant de CSV qui lui ne savait pas le faire.
[^] # Re: plop
Posté par Moogle . Évalué à 4.
Forcément on évite de commiter du code à moitié terminé et on se sépare les tâches pour ne pas tous bosser sur le même fichier en même temps, mais ça marche plutôt pas mal.
La feature "pouvoir commiter son propre truc perso", c'est justement ce qui me semble relever de GIT (ou autre décentralisé) plus que de SVN pour qui c'est justement une vraie limitation.
En changeant de boîte, j'ai vu qu'ils faisaient une branche pour chaque dév, ça me semble quand même assez crado de faire chacun dans son coin puis merger tout à la fin avec une liste de conflits longue comme le bras.
Donc est-ce que j'ai vraiment tout faux depuis le début ?
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 0.
Déjà, éviter de commiter du code est la pire connerie possible. Souvent ça se termine par quelques cas de figures :
- le code n'est de toute façon pas commité
- ça dure trop longtemps, comme il n'y a pas d'historique c'est galère de savoir ce qui a été fait, refait, défait, etc
- un bug, une tâche ou une demande impromptue arrive, comme c'est pas commité mais qu'on veut pas tout perdre on fait les deux en même temps et c'est la merde
Ensuite, séparer les tâches ok, séparer les fichiers ... c'est juste une limitation de svn, car il n'y a pas besoin, nécessité avec un vrai gestionnaire de source.
Evidemment si tout le monde à sa branche et fait nimp, ça déconnera lors des merges. De l'autre côté, avoir sa branche n'empêche pas de bien séparer son taff donc il n'y a pas de prob normalement (et beaucoup de conflits sont gérés par le dcvs, c'est leur force de se baser sur le merge comme opération de base)
> j'ai vraiment tout faux depuis le début ?
non, point.
Mais il y a beaucoup mieux et productif à faire !
Voir par exemple les liens que j'ai donné plus haut, ça ne parle pas forcément de 1 branche par dev, mais c'est des pistes intéressantes.
Le principe des dcvs c'est en gros : tu commit tout le temps, chaque truc, tu ne perd jamais l'historique, et ensuite tu merge et tu passes à la suite (vu que le merge est simple tu passes pas 3 plombes dessus)
[^] # Re: plop
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Pas seulement. Tu peux aussi nettoyer ton historique avant d'envoyer, et donc tes conneries intermédiaires restent privées (mais tu les avait quand même commitées en local), tu n'embêtes pas le reste du monde avec. C'est pas toujours souhaitable, mais c'est quasi-indispensable dans un contexte où la revue de code est importante.
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
mais le principe est bien là
En gros, les dcvs ça ne sert pas forcément (le D j'entends) mais les gestionnaires de sources un tant soit peu évolués (basés sur le merge, commit locaux, etc) sont maintenant indispensables pour moi.
Si j'avais l'équivalent sans le côté pleinement distribué je l'utiliserai quand même (bien que le côté distribué soit intéressant, même dans de petites équipes)
[^] # Re: plop
Posté par Stibb . Évalué à 1.
Ce qui m'énerve avec SVN ou CVS, c'est parfois, ma branche diverge, je me mets à jour avec le trunk, il y a des conflit, je gère je règle. Puis je continue. Je me remet à jour. Et tous mes conflits déjà résolu réapparaissent. Parce que je n'ai pas le bon nombre de commit, parce que je n'ai pas telle extension SVN ou pour une raison X ou Y, le truc ne se fait pas comme il faut et il faut recommencer. C'est inadmissible.
Je suis habitué à développer dans ma branche pour effectué des petits tags intérmédiaire (tel truc fonctionne maintenant, etc) avant de commiter. Le développement incrémentiel est indispensable. Mais je ne VEUX pas perdre du temps dans un merge alors que le logiciel a toutes les informations (ou devrait l'avoir) pour le faire comme il faut.
Le coté décentralisé ne m'attire pas plus que ça au final, on reproduira un comportement centralisé (un golden repository chez qui tout le monde commit). Et ça me gene même un peu, le fait qu'une personne ne puisse pas facilement prendre ta branche comme du dit "prend ma branche de dév truc_machin, il faut configurer un "remote, ...". Complexe.
Mais le merge de git, j'ai gouter, j'ai vu, et je veux la même chose à la maison !
[^] # Re: plop
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Tu n'as pas besoin de configurer un remote pour accéder à une branche. Tu as besoin de ça pour accéder à un autre repository. Mais rien ne t'empêche d'avoir plusieurs branches dans le même repository git.
[^] # Re: plop
Posté par Stibb . Évalué à 1.
tu créé tes branches en local. Tres bien. Mais il faut rajouter une étape, "push" pour envoyer ta branche sur le repo "centrale". Ou alors il faut que ton collegue configure un "remote" pour acceder à ta branche local.
git j'adore, mais j'apprécie aussi la centralisation de SVN (tout sur le même serveur, tu n'as qu'a connaitre le nom de la branche de dev du pote et tu peux travailler dessus).
[^] # Re: plop
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Oui, c'est pas un scoop qu'il faut faire un push pour envoyer des commits sur un repo distant. Mais le fait que le commit soit sur une autre branche ou pas ne change pas grand chose.
Si tu aimes travailler en centralisé, travaille en centralisé avec Git, il te suffit de faire un push derrière chaque commit (éventuellement un "push --set-upstream").
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
Et là fin du commentaire ne pose pas de problème, un repo central et tout le monde fait un git clone ce celui-ci, tout le monde push ses branches dessus, donc pas de prob, tu peux le faire avec git.
Il y a une commande git pour ça !
[^] # Re: plop
Posté par barmic . Évalué à 2.
Le problème se situait dans le fait de ne pas pouvoir utiliser le protocole git à cause d'administrateurs nazis qui laissent passer que HTTP(S).
Et on a bien réussi à travailler avec uniquement des mail générés par git ^^
C'est chiant mais ça marche.
(Pour info on avait pas la possibilité de modifier la conf' du serveur du dépôt et on utilisait une forge)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plop
Posté par tesiruna . Évalué à 2.
[^] # Re: plop
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plop
Posté par Albert_ . Évalué à 4.
Ca sent l'admin qui a installe une fois son syteme, fait si il veut des mises a jour et dors le reste du temps dans son bureau.
[^] # Re: plop
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Et incompétents. C'est à cause d'abrutis comme ça qu'un finit par tout faire à travers du HTTP, et que leurs règles débiles ne servent plus à rien puisqu'on les contourne.
[^] # Re: plop
Posté par Stibb . Évalué à 1.
Résultat tout passe sur HTTP.
[^] # Re: plop
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: plop
Posté par Gof (site web personnel) . Évalué à 3.
Cela est nécessaire pour des outils comme git-bisect. (très utile)
Mais je comprends tout à fait l'interêt de commiter tout le temps. Il faudrais pouvoir séparer les commits qui compiles et celle qui sont "travail en cours" ne compiles pas pour que git-bisect puisse quand même fonctionner.
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
* des outils tels stgit, Mq ou autre
* des branches locales (ou pas) perso qu'on merge ensuite
A lire, on peut croire qu'il ne faut pas qu'il y ait de commit qui ne build pas. En réalité, de moins point de vue, c'est faux. Il ne faut pas de commit qui ne build pas, dans les branches publiques. Dans une branche perso, une branche d'expérimentation, etc ça ne pose pas de problème.
L'avantage des dcvs est justement de permettre en général d'avoir le meilleur des deux mondes ;)
[^] # Re: plop
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
"git rebase -i" (y'a une extension Histedit pour Mercurial qui a l'air de faire grosso-modo pareil) est excellent aussi.
[^] # Re: plop
Posté par CrEv (site web personnel) . Évalué à 2.
Mais la philosophie est différente, dans le cas d'un rebase on modifie l'historique après coup (ou plutôt non pas l'historique mais ce qu'on va envoyer)
Avec Mq, stg c'est plus une manière de travailler
Au début, j'avais essayé une première fois stg sans trouver à quoi ça servait ni l'intérêt et, pour une raison très merdique (git-svn, pas de merge, que du rebase et du cherry-pick pour moi) je voulais avoir un historique clean lorsque je développe. Donc j'ai retenté stg et là ce fut une révélation !
A tel point que je ne me vois pas trop travailler sans un procédé similaire désormais.
[^] # Re: plop
Posté par Stibb . Évalué à 1.
branche de maitnenance, trunk => ca doit compiler, voir meme (celon politique de la boite) ça doit passer un certain nombre de test automatiques.
[^] # Re: plop
Posté par Stibb . Évalué à 1.
# eclipse + hgtk
Posté par blobmaster . Évalué à 5.
Le plugin mercurial de eclipse ayant certaines limites.
Il faut voir qu'avec ces logiciels de gestions de sources, tu as des fonctionnalités qui n'existe pas dans SVN et qui ne sont pas pas intégré (intégrable?) dans eclipse.
Par exemple le suivi de fichiers déplacé est mal foutu. Eclipse ne délpace pas il recré puis supprime. du coup pour hg c'est plus le même fichier alors qu'en ligen de commande "hg mv fichier" préserve l'historique.
Le merge hgtk est excellent, tout graphique et tout et tout.
Et la gestion de clones aussi.
Avec une petite équipe, on a vite fait de se sync dans tous les sens et hgtk gardant la liste des dépots en mémoire (avec un nom) tu vas super vite.
En plus (comme je l'ai dit plus haut) avec hgtk tu as une IHM cohérente avec tortoise si tu travailles aussi sous windows, c'est plutôt pas mal.
Je connais clearcase, svn et cvs et maintenant que j'utilise hg, je le regrette pas. J'en suis super content.
J'avais regardé git à un moment mais cela m'était apparu plus compliqué à utilisé que hg et à l'époque (peut-être encore aujourd'hui) inutilisable sous Windows.
[^] # Re: eclipse + hgtk
Posté par Philippe F (site web personnel) . Évalué à 5.
- les commandes ont des noms relativement intuitifs
- il y a moins de commandes
- la doc et le tutorial sont très bien foutus
- ca marche nickel sous windows, alors que j'ai eu des problèmes avec git
- au niveau GUI, ceux que j'ai eu l'occasion d'utiliser pour git me donnait l'impression d'être dans les années 80. Alors que avec TortoiseHg ou hgtk, j'ai plus l'impression d'être au 21e siècle.
A mon sens, git, même s'il est très puissant souffre d'un côté hardcore developer qu'on ne retrouve pas sous mercurial. Et ça s'en ressent, dans les doc, dans le tutoriaux, dans les GUI, dans les messages d'erreurs, dans l'aide des commandes, etc.
git a quand même été développé par un mec qui gérait des milliers de patch avec l'email comme seul outil.
Il est d'ailleurs significatif que des gens qui apprécient git se permettent de t'expliquer que tu as tort de ne pas utiliser la ligne de commande.
Sinon, hg, c'est quand même un caractère de moins à taper que git, faut surtout pas l'oublier.
[^] # Re: eclipse + hgtk
Posté par Stibb . Évalué à 2.
Hg, c'est surtout 2 caractères proches sur le clavier ;)
Je pense effectivement qu'il y a une notion de "culture" dans les projets : un projet qui a une culture de simplicité et de courbe d'apprentissage pas trop dûr engendrera un écosysteme d'outils avec la même approche. Git est hardcore et tous les projets autour le sont, malheureusement j'ai l'impression.
[^] # Re: eclipse + hgtk
Posté par Littleboy . Évalué à 5.
En meme temps, les mainteneurs de git en ont en gros pas grand chose a foutre de windows. Et le mainteneur du port non-officiel msys est un peu lourdaud sur les bords (meme si on lui en veut pas trop, il fait ca sur son temps libre), avec ses menaces de tout laisser tomber si quelqu'un ose faire un build x64 avec MSVC, ses trips sur les conversions CR+LF <-> CR et son mepris pour les utilisateurs windows (du coup on se demande pourquoi il passe du temps sur ce projet...).
Du coup, utiliser git sous windows, il faut vraiment aimer souffrir et faire avec des bugs en pagaille et une integration a chier.
Mercurial + TortoiseHg, avec les plugins SVN & GIT, c'est autre chose niveau integration et facilite d'utilisation.
[^] # Re: eclipse + hgtk
Posté par Antoine . Évalué à 4.
Tu veux dire que git est un peu le templeet des systèmes de gestions de versions ?
# egit
Posté par Albert_ . Évalué à 3.
Actuellement ce qui manque le plus a mon avis c'est la gestion des depots utilisant gitosis (ou equivalent). En gros egit demande le mot de passe alors qu'il y a la cle ssh et donc tu ne peux pas "fetcher" et "pusher" sur ce genre de depot de facon graphique. Mais si quelqu'un connais la methode je suis preneur.
[^] # Re: egit
Posté par Albert_ . Évalué à 1.
http://wiki.eclipse.org/EGit/User_Guide
mais elle me semble un peu obsolete avec Helios (a verifier).
[^] # Re: egit
Posté par Stibb . Évalué à 1.
[^] # Re: egit
Posté par Albert_ . Évalué à 1.
pour l'historique des dossiers en effet je ne vois pas et cela m'etonne aussi car je l'avais vu un temps. Enfin je me suis apercu que je m'en sors plus vite et mieux avec la ligne de commande donc bon c'est juste par curiosite que je teste ca de temps en temps.
# Première ligne, premier troll
Posté par Graveen . Évalué à 10.
Bonne plaisanterie ! Que GIT soit meilleur que SVN, pourquoi pas. Que SVN soit un faux gestionnaire de version, merci l'intégrisme.
[^] # Re: Première ligne, premier troll
Posté par Albert_ . Évalué à 0.
[^] # Re: Première ligne, premier troll
Posté par DLFP est mort . Évalué à 9.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Première ligne, premier troll
Posté par Stibb . Évalué à 8.
SVN est un gestionnaire de version de dossier, pas de résition de l'arbre de code dans le sens le plus pûr.
SVN est presque idéal néanmoins:
- renomme un fichier et tu es mort lors des merges (rien que ça ça décridibilise la notion de gestionnaire de code)
- les merges demandent trop d'effort (je suis faignant). Je dois faire attention de ne pas oublier un commit lors d'un merge, alors que ce que je veux c'est "branche A => Branche B". Merci au revoir. C'est possible de le faire, l'ancètre commun est facile à trouver. Git et Hg le font très bien. Collabnet et son merge utility permet de simplifier le truc, néanmoins ce n'est pas idéale.
Maintenir une branche de dev et une branche de production doit être le plus simple possible, avec une vue claire de ce qui est appliquée ou pas. Et surtout une vue efficace des merges. Sur les projets SVN, j'utilise le plugin revision history de trac, qui est pas mal (mais il manque des svn:info.... pourquoi il y a des "extensions" (loi de murphy, qui dit extention dit forcément "manquante") comme ça, alors que ça devrait être obligatoire.
# et pourquoi pas bazar ?
Posté par manatlan (site web personnel) . Évalué à 2.
[^] # Re: et pourquoi pas bazar ?
Posté par CrEv (site web personnel) . Évalué à 2.
(en même temps une gui c'est bien mais vu comment ça rame... peut-être que sur de petits code ça tourne, mais sur un vrai bon soft, c'est la merde absolue...)
[^] # Re: et pourquoi pas bazar ?
Posté par manatlan (site web personnel) . Évalué à 1.
http://bazaar.canonical.com/en/
[^] # Re: et pourquoi pas bazar ?
Posté par Stibb . Évalué à 1.
# Magit
Posté par Renaud Casenave-Péré . Évalué à 1.
Mais du coup, faut passer à Emacs...
# Une bonne GUI pour git et pour mercurial:
Posté par Gof (site web personnel) . Évalué à 9.
[^] # Re: Une bonne GUI pour git et pour mercurial:
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Une bonne GUI pour git et pour mercurial:
Posté par auve . Évalué à 1.
[^] # Re: Une bonne GUI pour git et pour mercurial:
Posté par yellowiscool . Évalué à 2.
En plus de ne pas gérer beaucoup de choses, il est vraiment très très lent (avec vim, c'est une horreur).
Les terminaux classiques lancés avec X11 sont vraiment plus utilisables, pourtant X11 sur mac, c'est peu réactif.
Envoyé depuis mon lapin.
# Tout dépends de ce que tu cherches
Posté par GeneralZod . Évalué à 6.
Pour bien connaitre les deux, j'estime que la principale différence est au niveau de l'interface utilisateur (en général).
Mercurial a été conçu pour être simple et extensible, git pour être le plus souple et rapide possible. Mercurial offre une interface plus simple à appréhender (moins de commande, moins d'options obscures) et la documentation en ligne est extrêmement bien faite. La plupart des commandes reprennent la sémantique de leur homologue svn ce qui facilite le passage depuis ce VCS.
Mercurial offre autant de possibilité que Git, la différence étant que les commandes non-essentielles sont fournis à travers des extensions (stash --> record, cherry-picking --> transplant etc ..), on n'utilise uniquement ce dont on a besoin. Je le précise parce qu'on m'a déjà posé la question, les extensions n'influent pas sur le format de dépôt et donc aucun problème d'intéropérabilité. La plupart des extensions sont inclus dans la distribution standard (et même supporté par les outils externes).
Pour une personne qui n'a jamais manipulé un DVCS (voire un VCS), c'est probablement un meilleur choix que Git qui offre une interface plus brouillon et des choix par défaut bizarres (même si ça c'est beaucoup amélioré depuis)
Git expose littéralement ses entrailles, ce qui demande quelques notions du fonctionnement interne de Git. Beaucoup de commandes, de notions nouvelles (staging area, stash, etc ...), contrairement à mercurial, il faut régulièrement passer le balai (git count-objects est ton ami) pour virer les merdes qui s'accumulent sous peine de perdre en perfs, ce qui rends la courbe d'apprentissage plus longue qu'avec mercurial mais il est indéniablement plus souple et très rapide.
C'est clairement un DVCS fait par et pour les power users.
Mercurial et Git sont tout à fait matures dans ton cadre d'utilisation, ils existent des plugins eclipse pour les deux DVCS (celui pour Mercurial est même plus mature qu'EGit), les deux offrent tout autant de possibilités. Si tu cherches un DVCS idiot-proof, je te recommanderais mercurial, si tu veux la puissance à moindre frais git
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.