> je vois vraiment pas ce que ca cree comme problem de tout mettre > publique
Je ne considère pas cette feature comme un moyen de ne pas mettre tout en public. Pas dans l'esprit "cacher" en tout cas. Simplement, comme c'est super facile et rapide de créer des branches, je les utilise pour le moindre "test", généralement, des trucs trop insignifiants pour mériter une branche publique dans le dépot publique. C'est plutôt dans cet esprit que je les utilise. Autant profiter du versionning jusqu'au bout. > 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 Suivant le contexte de travail oui c'est sûr. Me concernant, je peux difficilement m'en passer. On prend l'outil qui nous convient. > essaye d'avoir un peu trop de binaries dans un repo git, et les clone > ca devient tres lourd > car justement tout est copié En général, on a justement pas trop de binaries dans un dépôt. Les dépendances sont gerées en externe. Les clone restent dans tous les cas très très rapide. Et puis, c'est pas comme si on faisait un clone tous les jours avec Git... Une fois au début du projet, et une fois chaque fois que tu changes de machine/poste. > que le protocol HTTP de git soit pourri, ca aussi ca me gonfle Ouais super. C'est pas pour rien qu'il y a un protocole Git, justement pour zapper le protocole HTTP. Mettre en place le protocole git, c'est quand même pas super compliqué. Suffit d'ouvrir le port 9418 (pour un accès externe, si on est en boîte et qu'on reste sur le LAN, pas besoin), de lancer le git-daemon et créer un user 'git'. Si y'a pas un pilote dans l'avion pour faire ça, faut changer de boîte. Le protocole HTTP avec git, c'est juste un fallback en cas de problème. > nan pas de git sur google code, que mercurial > (jsutement a cause du problem de HTTP de merde de git) Je suis au courant (d'où la migration de mes projets sur Github). Je parlais de SVN. Pour le HTTP, même remarque que plus haut. Sinon +1 pour la ligne de commande. On 20 oct, 15:59, zwetan <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
