--- " Et ? ça reste un concurrent quand même. Sauf à vouloir être malhonnête, tu supprimes pas tout une partie du paysage pour le plaisir " (...)
Ai-je dit le contraire ? Mon propos est de comparer des cas semblables: CVS/SVN/HG/GIT.
Ils sont open source, et visent le même public.
Ce qui est malhonnête ce serait de prétendre que comparer Perforce (commercial) avec Git (GPL?) est pertinent.
A la limite on devrait discuter de ce qu'IBM et Microsoft ont, là tu serais plus logique.
Je ne supprime pas le paysage puisque dans les faits, chacun y trouve son compte, et sur le terrain tu ne me feras pas croire que la majorité reste en dehors des mains des 4 acteurs: CVS/SVN/GIT/HG.
Et la tendance est d'aller vers Git, ce que tu confirmes.
--- " Parce que moi, c'est pas la réponse qu'on m'a donné. Avant d'affirmer des trucs, prends au moins la peine de discuter autour de toi, ou plutôt, discute avec des gens qui savent de quoi ils parlent " (...)
Tiens tu me disais fièrement que c'est le patron qui décide...
Maintenant, c'est un codeur ...
En gros, une VCS de chez IBM ou Microsoft ne vaudrait pas un clou donc ils veulent du git, pour les perfs uniquement ?
Pour les perfs je ne sais pas, mais pour la stratégie d'une entreprise, elle prendra ce qui est utilisé par de grand projet comme kernel.org par exemple.
Donc git est pertinent. Mais même si c'est pertinent j'ai lu quelque part une fois que parfois il y a des problèmes (merge) mais c'était réglé finalement.
Donc dans mon cas, je compile git (en lisant le changelog je sais si c'est une version correcte ou pas).
Une fois la compilation s'est très mal passée... ce qui de mon point de vue explique pourquoi il y en a encore des tas qui restent chez hg ou même svn.
Parce que justement, il faut un truc qui marche mais pas un truc qui bogue en production.
--- " laisse moi deviner, parce que mettre en place git, ça implique du travail et des formations, et donc que les boites n'ont pas le temps ? En fait, tu devrait aller demander à ces nombreuses entreprises, car moi, mon employeur, et celui d'avant, ils ont commencer, voir bien fini de migrer vers Git " (...)
--- " Sinon, comme tu connais ni git, ni svn, cf ce que tu dis, peut être que tu devrais arrêter de commenter, car ça, c'est bien la définition d'inutile " (...)
1) Ah bon, il n'y a pas de commande chez git qui permet de dupliquer un dépôt svn vers un dépôt git ? Bizarre.
2) Formation: J'ai mal lu ?
a) D'habitude tu me traites d'imbécile, de demeuré, de pitoyable, et je ne sais quoi... [cela n'engage que toi bien sûr, pas LinuxFR]
b) Donc, le dernier des derniers que je suis est capable d'apprendre tout seul svn, puis git et enfin fossil.
c) La doc de git est tellement imbuvable que ma pauvre personne insignifiante est le seul en ce monde à être capable d'apprendre sans coach ni formateur grâce au seul tutorial officiel.
d) De plus, les super ingénieurs qui me surpassent en intelligence, notamment certains sur linuxfr, ne seraient pas capable d'apprendre un peu le git, même les commandes simples comme merger, commiter, brancher... ?
e) C'est vrai que la commande git svn ne permet pas de faire du git avec un dépôt svn. Faut que je revérifie ce que git peut faire dès fois que je me trompe. Git - SVN Crash Course
Peut-être que le site ci-dessus ce n'est pas top ? Bon alors celui-ci me paraît être très bien... git-svn - Git SCM Wiki
Ca doit être hyper dur à apprendre dis moi...
Puisque plusieurs membres de LinuxFR me prennent pour le bouffon de service je pense donc qu'un super ingénieur devrait s'en sortir sans problème, puisque je m'en sors.
3) Oui, migrer c'est difficile [résistance au changement par exemple], mais pas insurmontable.
Tous les IDE par exemple, ont intégré les VCS les plus courants (HG/GIT/SVN), donc la formation n'est pas forcément le soucis numéro un.
--- " C'est bien, d'un coté, tu dis "Je ne connais pas la politique de Google dans le domaine de VCS", de l'autre, tu dis " C'est pour cela que Google dans le passé utilisait Perforce (sécurité, assurance, etc.).". Tu as pas le sentiment de te contredire ? " (...)
Non.
Je disais que dans le passé il fallait un VCS de qualité. Donc la logique devrait être, de mon point de vue, faire un appel d'offre sur un VCS dans lequel on fait savoir quels sont leurs exigences (cahier des charges).
Donc, probablement que Perforce a gagné cet appel d'offre. Mais à titre personnel je ne connais pas la stratégie de Google dans le domaine de VCS.
Par contre, si j'étais Google, pour pouvoir capter les meilleurs, il vaut mieux se tourner vers le VCS le plus utilisé du moment et qui est décentralisé: git.
Tu utilises git non? Moi de moins en moins car je préfère Fossil.
Merci coach pour cette partie de rigolade. Merci pour le +1, aussi.
[^] # Re: C'est plus facile de travailler salement...
Posté par kadalka . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à -9.
Ai-je dit le contraire ? Mon propos est de comparer des cas semblables: CVS/SVN/HG/GIT.
Ils sont open source, et visent le même public.
Ce qui est malhonnête ce serait de prétendre que comparer Perforce (commercial) avec Git (GPL?) est pertinent.
A la limite on devrait discuter de ce qu'IBM et Microsoft ont, là tu serais plus logique.
Je ne supprime pas le paysage puisque dans les faits, chacun y trouve son compte, et sur le terrain tu ne me feras pas croire que la majorité reste en dehors des mains des 4 acteurs: CVS/SVN/GIT/HG.
Et la tendance est d'aller vers Git, ce que tu confirmes.
Tiens tu me disais fièrement que c'est le patron qui décide...
Maintenant, c'est un codeur ...
En gros, une VCS de chez IBM ou Microsoft ne vaudrait pas un clou donc ils veulent du git, pour les perfs uniquement ?
Pour les perfs je ne sais pas, mais pour la stratégie d'une entreprise, elle prendra ce qui est utilisé par de grand projet comme kernel.org par exemple.
Donc git est pertinent. Mais même si c'est pertinent j'ai lu quelque part une fois que parfois il y a des problèmes (merge) mais c'était réglé finalement.
Donc dans mon cas, je compile git (en lisant le changelog je sais si c'est une version correcte ou pas).
Une fois la compilation s'est très mal passée... ce qui de mon point de vue explique pourquoi il y en a encore des tas qui restent chez hg ou même svn.
Parce que justement, il faut un truc qui marche mais pas un truc qui bogue en production.
1) Ah bon, il n'y a pas de commande chez git qui permet de dupliquer un dépôt svn vers un dépôt git ? Bizarre.
2) Formation: J'ai mal lu ?
a) D'habitude tu me traites d'imbécile, de demeuré, de pitoyable, et je ne sais quoi... [cela n'engage que toi bien sûr, pas LinuxFR]
b) Donc, le dernier des derniers que je suis est capable d'apprendre tout seul svn, puis git et enfin fossil.
c) La doc de git est tellement imbuvable que ma pauvre personne insignifiante est le seul en ce monde à être capable d'apprendre sans coach ni formateur grâce au seul tutorial officiel.
d) De plus, les super ingénieurs qui me surpassent en intelligence, notamment certains sur linuxfr, ne seraient pas capable d'apprendre un peu le git, même les commandes simples comme merger, commiter, brancher... ?
e) C'est vrai que la commande
git svnne permet pas de faire du git avec un dépôt svn. Faut que je revérifie ce que git peut faire dès fois que je me trompe.Git - SVN Crash Course
Peut-être que le site ci-dessus ce n'est pas top ? Bon alors celui-ci me paraît être très bien...
git-svn - Git SCM Wiki
Ca doit être hyper dur à apprendre dis moi...
Puisque plusieurs membres de LinuxFR me prennent pour le bouffon de service je pense donc qu'un super ingénieur devrait s'en sortir sans problème, puisque je m'en sors.
3) Oui, migrer c'est difficile [résistance au changement par exemple], mais pas insurmontable.
Tous les IDE par exemple, ont intégré les VCS les plus courants (HG/GIT/SVN), donc la formation n'est pas forcément le soucis numéro un.
Non.
Je disais que dans le passé il fallait un VCS de qualité. Donc la logique devrait être, de mon point de vue, faire un appel d'offre sur un VCS dans lequel on fait savoir quels sont leurs exigences (cahier des charges).
Donc, probablement que Perforce a gagné cet appel d'offre. Mais à titre personnel je ne connais pas la stratégie de Google dans le domaine de VCS.
Par contre, si j'étais Google, pour pouvoir capter les meilleurs, il vaut mieux se tourner vers le VCS le plus utilisé du moment et qui est décentralisé: git.
Tu utilises git non? Moi de moins en moins car je préfère Fossil.
Merci coach pour cette partie de rigolade. Merci pour le +1, aussi.