Tiens tu me disais fièrement que c'est le patron qui décide...
Tu sembles confondre tes propos avec mes propos. SI j'ai dit ça, je demande une citation et un lien vers le commentaire linuxfr. J'ai marre que mon nom soit cité par un mec qui est incapable de comprendre les trucs basiques.
Et tu sembles diviser une entreprise en 2 groupes totalement distinct, sans imaginer qu'il y a discussion possible, je sai spas dans quel PME est ce que tu as bossé, mais ça devait pas être la joie.
En gros, une VCS de chez IBM ou Microsoft ne vaudrait pas un clou donc ils
veulent du git, pour les perfs uniquement ?
Alors 2 choses :
1) Cite les noms des produits, ça te fera déja moins passer pour un rigolo. EN l’occurrence, tu peux dire clearcase et sourcesafe.
2) Safesource ne tourne que sous windows, ne s'intégre que avec windows, et n'a que des clients windows. Autant dire que si tu as pas déja choisi windows partout, tu peux te brosser.
3) clearcase te force plus ou moins à tirer un serveur d'application webspahre, ce qui requiert d'avoir deja des admins J2EE, ce qui n'est pas forcement le cas ou la voie que tout le monde veux prendre.
Donc non, on est pas dans ton monde binaire ou soit une chose est bien, soit tout pourri. Il y a des contraintes sur ce que tu connais, ce que tu veux faire, ton archi existante, ton équipe existante.
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.
Cool, donc hg est utilisé par python et par mozilla, et bzr est utilisé par Canonical et Ubuntu, mysql, emacs. Fossil est utilisé par rien.
2) Formation: J'ai mal lu ?
Y a plein de chose que tu fait mal, mais lire en fait pas parti. Par contre, il est fort probable que tu penses que "pouf, les codeurs comprennent comment marche git du premier coup", ce qui montre une fois de plus ta déconnexion complète avec le monde réel. Dans le monde réel, tes codeurs peuvent venir d'une SSII ou ils ont pas appris à se servir de git/svn/etc, sortir d'école ou l'idée de gestion de version n'est pas au programme, et donc passer d'un modéle centralisé à un modéle plus complexe requiert des formations. Venant de svn, le rebase est une idée simple mais qui n'etait pas possible. Le cherrypick non plus. La façon de faire un pull propre sans faire des commit de merge aussi. Bref, y a plein de choses que tu connais pas sur git et qu'une formation permet de clarifier.
D'habitude tu me traites d'imbécile, de demeuré, de pitoyable, et je ne sais
quoi...
Je ne pense pas avoir dit que tu es un imbécile, juste que tes propos sont imbéciles. J'ai des mots beaucoup plus dur pour l'ignorance crasse que tu affiches à longeur de temps, mais que je garde tant bien que mal par civilité.
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... ?
Cf ce que j'ai dit plus haut. Tout le monde n'a pas la chance comme toi d'avoir du temps libre pour le passer en auto formation, et si tu as du te former pour utiliser l'outil, ça prouve bien qu'il faut une formation, cqfd. Sauf à demander aux gens de le faire hors du boulot, ce qui serait au mieux un procédé cavalier, et au pire sans doute un peu illégal.
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.
Alors une fois de plus, tu emploies des mots pour dire autre chose que le sens officiel. Un appel d'offre, c'est une procédure bien spécifique avec divers parties qui répondent, c'est utilisé principalement pour l'état. Je pense que ce que tu veux dire, c'est sans doute une comparaison.
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.
Je peux te garantir que même à l'époque ou Perforce était utilisé par défaut, le VCS n'avait pas d'impact sur les recrutements vu qu'il y a suffisamment d'outils par dessus pour cacher les aspects les plus moches. De plus, vu que tu n'as pas le droit de transférer le code source sur ton portable (pour les applications internes, je parle pas de trucs spéciaux comme go, chromium ou les divers projets libres de la boite) et qu'il faut bosser via ssh sur des serveurs sécurisés, les parties "pas de travail offline" et "trop lent" sont moins ennuyeuses que dans un déploiement classique.
[^] # Re: C'est plus facile de travailler salement...
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 3.
Tu sembles confondre tes propos avec mes propos. SI j'ai dit ça, je demande une citation et un lien vers le commentaire linuxfr. J'ai marre que mon nom soit cité par un mec qui est incapable de comprendre les trucs basiques.
Et tu sembles diviser une entreprise en 2 groupes totalement distinct, sans imaginer qu'il y a discussion possible, je sai spas dans quel PME est ce que tu as bossé, mais ça devait pas être la joie.
Alors 2 choses :
1) Cite les noms des produits, ça te fera déja moins passer pour un rigolo. EN l’occurrence, tu peux dire clearcase et sourcesafe.
2) Safesource ne tourne que sous windows, ne s'intégre que avec windows, et n'a que des clients windows. Autant dire que si tu as pas déja choisi windows partout, tu peux te brosser.
3) clearcase te force plus ou moins à tirer un serveur d'application webspahre, ce qui requiert d'avoir deja des admins J2EE, ce qui n'est pas forcement le cas ou la voie que tout le monde veux prendre.
Donc non, on est pas dans ton monde binaire ou soit une chose est bien, soit tout pourri. Il y a des contraintes sur ce que tu connais, ce que tu veux faire, ton archi existante, ton équipe existante.
Cool, donc hg est utilisé par python et par mozilla, et bzr est utilisé par Canonical et Ubuntu, mysql, emacs. Fossil est utilisé par rien.
Y a plein de chose que tu fait mal, mais lire en fait pas parti. Par contre, il est fort probable que tu penses que "pouf, les codeurs comprennent comment marche git du premier coup", ce qui montre une fois de plus ta déconnexion complète avec le monde réel. Dans le monde réel, tes codeurs peuvent venir d'une SSII ou ils ont pas appris à se servir de git/svn/etc, sortir d'école ou l'idée de gestion de version n'est pas au programme, et donc passer d'un modéle centralisé à un modéle plus complexe requiert des formations. Venant de svn, le rebase est une idée simple mais qui n'etait pas possible. Le cherrypick non plus. La façon de faire un pull propre sans faire des commit de merge aussi. Bref, y a plein de choses que tu connais pas sur git et qu'une formation permet de clarifier.
Je ne pense pas avoir dit que tu es un imbécile, juste que tes propos sont imbéciles. J'ai des mots beaucoup plus dur pour l'ignorance crasse que tu affiches à longeur de temps, mais que je garde tant bien que mal par civilité.
Cf ce que j'ai dit plus haut. Tout le monde n'a pas la chance comme toi d'avoir du temps libre pour le passer en auto formation, et si tu as du te former pour utiliser l'outil, ça prouve bien qu'il faut une formation, cqfd. Sauf à demander aux gens de le faire hors du boulot, ce qui serait au mieux un procédé cavalier, et au pire sans doute un peu illégal.
Alors une fois de plus, tu emploies des mots pour dire autre chose que le sens officiel. Un appel d'offre, c'est une procédure bien spécifique avec divers parties qui répondent, c'est utilisé principalement pour l'état. Je pense que ce que tu veux dire, c'est sans doute une comparaison.
Je peux te garantir que même à l'époque ou Perforce était utilisé par défaut, le VCS n'avait pas d'impact sur les recrutements vu qu'il y a suffisamment d'outils par dessus pour cacher les aspects les plus moches. De plus, vu que tu n'as pas le droit de transférer le code source sur ton portable (pour les applications internes, je parle pas de trucs spéciaux comme go, chromium ou les divers projets libres de la boite) et qu'il faut bosser via ssh sur des serveurs sécurisés, les parties "pas de travail offline" et "trop lent" sont moins ennuyeuses que dans un déploiement classique.