Salut eka, Difficile d'en parler dans un post car c'est à l'utilisation qu'on remarque les avantages.
Déjà sous mac, iteratif parlait de Git GUI comme interface graphique qui semble excellente. Après tu as évidemment la ligne de commande (j'en suis resté là pour toutes les opérations). Pour l'installation, 'sudo apt-get install git- core' sous linux suffit (sous mac ça doit être port au lieu de apt-get si je me goure pas). De mon point de vue, les fonctionnalités qui me paraissent essentielles : * la manière dont sont gerées les branches : dès que tu as besoin de tester un truc, tu fais une branche. Tu peux delete ou remerger si ça réussit ou pas. Tu peux créer des branches dans ton dépot local qui n'apparaitront jamais dans le dépot distant. * L'utilisation offline : on peut tout faire en local, on n'est pas dépendant d'un dépot distant et on peut même s'en passer. Cela permet de fonctionner sur d'autres types de workflow, sans dépot distant, où avec plusieurs dépôts qui jouent des rôles différents (un dépot maitre, des dépots intermédiaires pour chaque module avec des responsables assignés qui commitent sur le dépot maitre, par exemple) Avec un scm classique, dans une équipe, si tu dev un truc et tes unittests ne passent pas, tu commit pas dans le dépot distant et t'es coincé. Tes modifs ne seront pas visibles dans le dépot distant tant que tout n'est pas ok, ce qui implique que tu peux pas versionner ton boulot tant qu'il est pas ok. Avec git, typiquement, tu fais une branche dès le départ pour ne pas toucher au master, donc tu peux versionner tes propres modifs sans influer sur le dépot principal, et merger quand c'est ok avec le master * La rapidité. On dit que c'est secondaire mais bon... un clone de dépot c'est super rapide, faire une branche, merger, c'est immédiat. * Après c'est un aspect pratique et peut-être personnel : avec svn, on se tape des repertoires .svn un peu partout dans les sources et je deteste avec de la pollution dans ce genre de répertoires. Avec Git, tu as un .git à la racine de ton projet et c'est tout. Supprimer le versionning du projet, c'est supprimer le dossier .git. * La durée pour mettre en place le versionning d'un projet : 'git init' et ça roule. Avec svn, il faut mettre en place ton dépot distant ce qui est assez chiant. Sinon utiliser des services comme Google Code qui le proposent mais bon... Evidemment c'est pas exhaustif, y'a encore plein d'autres choses, et aussi souvent des subtilités à l'utilisation .Après le mieux, c'est de le tester soi même sur un projet pour s'en rendre compte. Après, faut rendre à SVN ce qui est à SVN. * Ok y'a plusse d'interfaces graphique pour l'utiliser. C'est vrai sous windows. Sous mac il y a Git GUI qui semble nickel, sous ubuntu y'a Giggle, pas mal. Y'a aussi gitk, une interface basique (et cross platform je crois, livrée de base avec git si je me goure pas). Personnellement, je reste convaincu de la ligne de commande pour l'utilisation journaliere d'un scm, et d'utiliser des GUI pour de la visualisation essentiellement, pas de la manipulation (voir les logs, commits, arborescence des branches, etc.) * Meilleur support sous windows. Pour Git, y'a cygwin pour la ligne de commande et ça marque nickel, sinon msysgit mais pas assez stable à mon gout. On 17 oct, 18:45, "dcz.switcher" <[email protected]> wrote: > Vraiment intéressant ce genre de discussion, c'est comme ça qu'on > découvre de nouvelles technos et qu'on a envie de s'y mettre > > bon week-end à tous, que vous soyez GIT ou SVN d'ailleurs : ) > > switcherdav > > Le 17 oct. 2009 à 18:37, lunar a écrit : > > > > > Mouais. Et y'a aussi tous les trucs que SVN ne peut pas faire, et > > toutes les limitations > > qu'il impose au niveau workflow (ouais parce que l'histoire des sous > > répertoires, c'est uniquement > > à cause de la philosophie d'SVN que t'es obligé de faire ce genre de > > trucs. Tellement c'est lourd > > de se créer des dépots qu'en général, t'en fais un mastoc où tu mets > > tout dedans > > (d'où la necessité de choper des sous répertoires pour récup son > > projet). D'ailleurs croisons les doigts > > pour pas qu'il y ait une merde dans le dépot... > > > Et ça tu t'en fous completement dans Git, tu fais un nouveau dépot en > > 2 sec. > > Aussi, les branches se font tellement facilement (et localement, très > > important) que j'hésite plus à en faire une dès que je veux > > expérimenter quelque chose. Très souvent, les profondeurs de branches > > augmentent et malgré ça, aucun souci en mergeant. Avec SVN, je me suis > > tjrs cassé les dents : lourd, chiant, doutes sur la fiabilité au > > moment du merge. > > > Bref je fais pas la liste complète parce qu'elle serait longue, et > > aussi parce que c'est inutile de vouloir convaincre des gens qui n'en > > ont pas envie :). Bref, mes convictions sur Git sont assez fortes, et > > moi aussi je rigole doucement, sur la viabilité de SVN de nos jours. > > > On 17 oct, 14:56, zwetan <[email protected]> wrote: > >>> Personnellement, j'acquiesce, j'ai jamais pu supporter SVN à > >>> l'utilisation et donc j'essaie de l'éviter le plus possible. > >>> Mais bon ça manque un poil de "tact" ce genre de déclarations ^^ > > >> au debut du thread qd je quote BCS qui dit > >> "Distributed systems really do handle complex merges better." > > >> c'est extremement ironique et je suis d'accord avec lui > > >> perso je mettrais toujours en avant SVN, et le reste c'est vraiment > >> quand je suis forcé > > >> je maudis pieds et mains que Mozilla utilise mercurial, > >> pas que mercurial est franchement mauvais, mais désolé il a de > >> grosses > >> limitations (tout comme Git) > > >> voirhttp://mercurial.selenic.com/wiki/UnderstandingMercurial > >> "What Mercurial can't do > > >> Many SVN/CVS users expect to host related projects together in one > >> repository. This is really not what hg was made for, so you should > >> try > >> a different way of working. This especially means, that you cannot > >> check out only one directory of a repository." > > >> et voirhttp://git.or.cz/gitwiki/GitFaq#HowdoIcloneasubdirectory.3F > >> "How do I clone a subdirectory? > > >> Currently, you cannot. There are plans for narrow and sparse clone > >> support. > > >> In the meantime, you can use the subdirectory-filter of git filter- > >> branch to extract a subdirectory. You can also merge changes back > >> using the subtree merge strategy. Or you can use submodules." > > >> pour un usage simple où un repo X veut juste un lien externe vers un > >> repertoire particulier d un repo Y, > >> svn-external ca le fait, mercurial et git ne peuvent pas faire ca > > >> pour un usage plus avancé où on utilise gclient pour organiser toute > >> une arbo (voir comment est organisé chromium), > >> avec chaque sous-dir qui correspond a un checkout svn (cad un path sv > >> pour chaque sousdir), > >> bah mercurial et git sont incapable de faire ca > > >> donc Linus qui nous sort que parce que CVS est "cassé" et que SVN se > >> veut un successeur de CVS donc SVN est lui aussi "cassé" > >> perso je rigole doucement > > >> zwetan > > --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe Groupe "FCNG" de Google Groupes. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour afficher d'autres options, visitez ce groupe à l'adresse http://groups.google.com/group/fcng?hl=fr -~----------~----~----~----~------~----~------~--~---
