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 -~----------~----~----~----~------~----~------~--~---
