> > 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). >
sudo port install git sudo port install mercurial > 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. euh subversion et mercurial pareil apres il y a branches et clone...pas exactement pareil > Tu peux créer des branches dans ton dépot local qui n'apparaitront > jamais dans le dépot distant. > c'est une bonne feature mais j'y vois 2 defauts 1) pas de branches ou clone publique ==> pas de communication dans un projet 2) pour du dev cross-platforme ca coince (eg. j ai besoin de tester le meme code sous OSX/Win/Linux etc.) > * 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) franchement le coté "tout local" , autant je peux voir l interet si tu es coincé dans un train ou un hotel sans connection internet, mais bon sinon bof bof je vois vraiment pas ce que ca cree comme problem de tout mettre publique > 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. si les nouvelles features sont dev dans une branche pour ca, non ca marche > 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 essaye d'avoir un peu trop de binaries dans un repo git, et les clone ca devient tres lourd car justement tout est copié je comprends la difference de concept etc... mais ce n'est pas non plus si svn empechait de faire ca oui les clone qui encourage le fork et les dev locaux dans git et hg, ok mais ca reste tres proche de faire un branch+merge dans svn vraiment le seul interet c'est si le repo est enorme (genre un repo mozilla) > * 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. bah forcement tout en local > * 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. euh ouaip je vois pas les .svn comme un problem un svn export c est vraiment pas dur par contre que git/hg ne supportent pas les repertoire vide, ca me gonfle que le protocol HTTP de git soit pourri, ca aussi ca me gonfle > * 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... > nan pas de git sur google code, que mercurial (jsutement a cause du problem de HTTP de merde de git) > 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. perso c est tout en ligne de commande comme ca sur n importe quel OS je reste aussi rapide ;) l autre avantage de mercurial (comparé a git) c'est que les commandes restent assez similaire de svn donc si on connait bien svn en cli, bah hg c est pas dur du tout --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
