ckyl a écrit 3877 commentaires

Dans ce sens tu vas vite te retrouver à recoder le VCS simple… Simplement par ce que le VCS lui même ne découvre qu'on est dirty qu'au moment ou on le lance. La seule optim facile est l'inverse. Si absolument rien n'a changé dans l'arbo alors l'état ne peut pas avoir changé et ca ne sert à rien de mettre à jour l'état. Mais pour savoir si c'est un cas fréquent il n'y a qu'une facon de le savoir: faire des mesures.

Mais il faut garder à l'esprit qu'actuellement tout repose PROMPT_COMMAND qui pointe sur un script shell… D'où ma question de savoir si ce design est adapté si l'outil est destiner à gagner en fonctionalités.

Git est extrêmment rapide et tu n'auras pas de problème à partir du moment où ton cache disque est suffisant (l'OS n'as pas à accéder au disque au cours de l'exécution de ca).

Tu peux avoir des problèmes pour deux raisons:

• Un VCS plus lent. Bzr est un bon exemple, il a un temps de démarrage significatif et inévitable qui se ressent très vite. Une commande passe, deux tu sens déjà une perte de réactivité
• Une station limite en RAM qui empêche le système de cacher les pages. Là tu peux prendre des blocages de quelques secondes. Plus t'es IO sont mauvais (VM) plus c'est sensible. J'ai pas mal ce cas au taff où je me balade dans beaucoup beaucoup de repo utilisant 4 VCS différents. Là tout les VCS sont impactés.

Après dès que tu fais une opération remote tu rentres dans un autre mode côté latence et robustesse. C'était le sens de ma remarque.

Ce que tu dis est faux. Tu es obligé de rafraichir tes informations à chaque fois car tu as de la concurrence, le monde bouge autours de toi et le seul moyen de t'en rendre compte est de demander. Un fichier peut avoir été édité, un commit à pu être fait dans un autre shell etc. Chaque shell doit donc rafraichir sa vue en permanence pour fournir des informations à jour…

Il me semble qu'il y a eu un joli refactoring sur les VCS qui a pas mal améilloré les perfs (au départ on invoquait deux fois chaque VCS). Mais optimiser ce fonctionnement n'est pas trivial et peut vite devenir très complexe à gérer, surtout dans le contexte de processus indépendants.

Avec ce genre de fonctionalité tu vas vite arriver aux limites du design actuel à cause du coup des opérations à refaire et non facilement mutualisables. Les VCS donnant déjà chaud à la machine (très assez visible dans les environements avec peu de cache disque).

Je pense que c'est envisageable mais qu'il faut d'une part viser à mutualiser les opérations entre les différents shells et d'autre part viser l'eventual consistency. Nojhan si le nombre de fonctionalités explose t'as déjà pensé à sortir les traitements dans un daemon qui pourrait à la fois mutualiser les calculs, avoir l'opportunité de faire les choses un peu plus intelligement que brute forcer et assurer une bonne interactivité  ?

Y'a un moment les gens veulent bosser. Donc les trips des admins à casser les couilles à tout le monde c'est relou et ca fait perdre plus de fric en productivité qu'autre chose.

Si un utilisateur abuse et ne fait pas son taff, c'est à son manager de le dégager pas aux admins de jouer à la police. Si un utilisateur nique le réseau, tu shoots effectivement le poste. Ca va forcement poser problème de ne plus avoir d'accès, ou un accès très dégradé, et tu reviens à la case discuter avec son manager. Mais les mesures globales, même du traffic shapping mal fait, c'est insupportable et plombe tout le monde.

On devrait forcer les admins à bosser sur les réseaux qu'ils administrent..

Alors beaucoup de gens vont devoir commencer à se poser sérieusement des questions sur leur vie

Clairement. Pour les raisons suivantes:

• Sur le concept: si tu as besoin de ca comme incitation pour décider et réaliser ce que tu dois et veux faire ça me fait juste flipper.
• Sur la réalisation: Avoir un système de point équilibré qui marche et qui répond à l'objectif c'est très compliqué à mettre en œuvre. Tu vas passer plus de temps à te masturber sur l'outil qui devrait t'aider à faire des choses qu'à faire les choses. Ta courbe et tes points ils veulent dire quoi et quelle est leur relation avec ton objectif initial ?
• Sur le rapport aux choses: Effectivement la carotte des points et des récompenses marche très bien. Tellement bien que si c'est totalement logique de l'exploiter pour les services afin de booster les contributions utilisateurs; c'est profondément stupide de se laissé aller la dedans pour l'utilisateur. Genre le mec qui regarde son karma ici, ou les médailles sur stackoverflow il s'est un peu perdu je pense et ca lui ferait du bien de réfléchir à pourquoi il fait les choses.
• Sur la distorsion objectif VS métriques: Les métriques sont des outils pour comprendre et prendre du recul sur son travail afin d'améliorer ses performances. Par contre les métriques ne sont pas l'objectif. Les utiliser comme tel est toujours une connerie contre productive.

Donc oui pour moi ca me semble ne faire qu'empirer la procastination, la paresse et la facilité; ce qui est assez drôle pour un outil visant l'inverse.

C'est une todolist intéressante, mais qui a peut-être tendance à prendre une place trop importante.

C'est surtout question que si coller une pauvre courbe d'XP à une TODO à une quelconque influence, il faut comment à se poser sérieusement des questions sur sa vie ou sa TODO…

Note que tout n'est pas noir ou blanc. Se faire sa place pour pouvoir bosser tu peux le faire dans une "boîte de merde" et beaucoup des problèmes sont du aux équipes elles même. J'ai déjà vu des différences phénoménales entre deux équipes avec le même contexte et management au dessus…

Certes, certes, sauf que les 10% de boites sérieuses restante, il y a du bon dev qui fait la queue pour y entrer, bref elles ont le choix … :)

Ca t'étonne tant que ca que les boites qui font les choses bien cherchent à recruter des gens compétents et pro ?

Mais soyons sérieux deux minutes. Actuellement on est un métier où les gens compétents sont très recherchés, très bien traités et payés. Les portes sont grandes ouvertes contrairement à beaucoup d'autres métiers qui se sont fait entièrement verrouiller.

C'est pas si simple.

En quoi ? C'est ton job !

Franchement l'organisation de ton équipe, la facon dont elle travaille et communique est vraiment primordial. Il y a vraiment moyen de travailler correctement en s'y prenant bien.

90% des devs ont conscience de taffer dans une des boites de merde

Il y a grosso modo autant de boite de merdes que de dev de merdes. La première partie finissant peu à peu part employer la seconde partie, les autres finissant inexorablement par aller voir ailleurs ou changer de métier.

Dans ces boites dire non à un projet c'est dire non à tous les projets de la boite.

Quel est le problème ? Si on te fait sciemment saborder les projets et perdre ton temps, c'est qu'il est tant d'aller voir ailleurs non ?

Il y a un juste milieu entre définir un cahier des charges exhaustif

Si c'est totalement possible par fonctionnalité et ton équipe ne devrait pas accepter du travail qui n'est pas correctement spécifié.

C'est pour ca qu'on fait par petit incrément. On laisse les managers décider "uniquement" de la fonctionnalité qu'ils veulent avoir dans le produit maintenant. On les force à définir exactement ce qu'ils veulent en leur fournissant toutes les informations utiles, et on revient vers eux pour l'étape suivante. Les devs/designers savent sur quoi bosser et ne perdent pas leur temps. Les managers ont exactement ce qu'ils demandent et peuvent se rendre compte qu'ils ne veulent pas toujours ce qu'ils ont demandé. Et si ca dérive c'est que la gestion des priorités a été mauvaise, que l'objectif à long terme n'était pas réaliste, ou qu'il y a eu des modification en court de route. Dans tout les cas, on peut tracer et comprendre pourquoi ca à foiré et s'en servir pour ne par refaire la même erreur. Les deux côtes du métier peuvent apprendre de cela et en discute pour ne pas que ca se reproduise.

Dans tout les cas, si tu acceptes du travail non défini ca va dans le mur.

Hors mon logiciel il doit servir aujourd'hui, pas quand Debian aura intégré python3-pyalsa dans stable (dans deux ou trois ans minimum ?).

Pourquoi ne pas utiliser un virtualenv ou assimilé ? C'est fait pour. Si tu ne veux pas avoir à demander d'accès réseaux pour l'instalation ou ne pas être vulnérable aux failles de sécurité de pip/pypi tu livres un pybundle en static.

Et donc, tu avais besoin d'une tablette à plusieurs centaines d'€ pour accéder à un site Web,

Il n'a pas dit ca. Il a seulement dit que tu disais des conneries sur l'inutilité des sites de recette.

l'ordinateur ne pouvait pas le faire ?

Il n'a pas dit ca non plus. Les deux peuvent le faire, les deux n'offre pas les mêmes avantages

Parce que personnellement, je regarde avec l'ordinateur, c'est probablement même plus rapide que de saisir sur la tablette,

Un jour tu essaieras au lieu de supposer. Tu sais pour aller sur le même site, entrer 30 caractères et cliquer sur 5 liens ca va pas faire masse de différence. Hormis que t'as besoin d'aller dans la pièce d'à côté, de le démarrer, de te logger, de recopier ta recette et d'éteindre le tout après.

pour sa santé matérielle en milieu hostile

Je me demande l'état de tes murs et ta facon de cuisiner… T'es pas non plus obliger de poser les choses sur les plaques chauffantes hein !

j'ai une confiance toute relative dans les recettes de cuisine rédigée par n'importe qui sur Internet, j'ai déjà vu passer des choses abominables. L'avantage d'un vieux bouquin de recettes,

Moi idem avec Wikipedia.

Sur Internet y'a que de la merde, et les utilisateurs peuvent poster ce qu'ils veulent je fais confiance qu'au bouquin. D'ailleurs ils offrent une bien meilleure expérience pour chercher et classifier les choses. De même qu'un rapport cout/utilité/encombrement encore non égalé.

la tablette à plusieurs centaines d'€ pour y accéder et ne faire quasiment que ça est très loin d'être indispensable

Par ce qu'il n'y a que toi qui a décidé que ca ne servait qu'à ca.

Les gens ont des usages. On leur offre un palette de matériel qui offrent différentes possibilités. Ils font leur choix. Qu'est ce que ca peut bien te faire quand bien même il ne ferait pas le meilleur choix ? Pourquoi tu te sens tellement supérieur toi utilisateur de desktop ?

Je viens de faire le calcul, juste pour rire. Avec les limites de l'oeil humain, il ne faut pas s'éloigner de plus de 3cm de l'écran pour être capable de distinguer deux pixels.

Et autrement pour rire ca donne quoi quand tu regardes les écrans ?

C'est surtout le fait d'indiquer StarOffice plutôt qu'OpenOffice ou LibreOffice qui fait un peu pitié pour une SSLL.

Tu sais SSII ou SSLL même combat hein ;)

C'est pour ca que tu utilises un proxy local qui soit fait suivre au proxy de l'entreprise soit balance tout sur l'interweb selon le réseau sur lequel tu te trouves. Ca doit même s'automatiser dans trop de problème.

Dans l'état actuel la solution au problème du proxy et donc un proxy de plus ;)

Dans des logiciels de gestion de versions décentralisée, on fait juste ça :

Merci je suis au courant ;)

Avec svn, on ne peut pas faire la même chose :

Tout mon propos c'est que si cette fonctionalité t'intéresse ca te prend 3 minutes chrono de t'écrire l'alias pour le faire. Bordel on parle d'automatiser 3 foutues commandes pour un dev. Si tu veux planquer ton repo dans ta working copy pour la mettre sur une clé USB il suffit de la mettre là. Il te faut après effectivement un alias pour faire le relocate automatiquement.

À propos du besoin de relocate t'es au courant qu'un DCVS comme bazaar te force aussi à faire un fixup à chaque fois que tu bouges ton clone ? Oui oui !

C'est pas pratique, de toute façon ce n'est pas vraiment fait pour cet usage.

Tu crois vraiment que c'est un critère ? Un commande de plus à la création du repo ? Sérieusement…

Y'a pourtant des centaines de raisons de choisir tel ou tel SCM pour ton besoin et ton workflow.

Sans compter qu'un DVCS est vraiment plus pratique de façon générale, par example si on n'est pas accès à internet temporairement on peut continuer à faire des commit.

Si ton dépôt est local comment dire ? Si tu as une origine distante alors pour l'obtenir tu as suivi exactement le même type de processus que tu décrivais comme pas pratique il y a 12 lignes ;)

Encore une fois ne vient pas me faire la réclame des DCVS, ce n'est pas le sujet. C'est juste une histoire d'honnêté intellectuelle quand on parle des possibilités d'un outil. Les deux affirmations auxquelles j'ai repondu sont juste entièrement mensongères. Après tu utilises ce que bon te semble.

Un dev n'est pas un admin. Moi en tant que dev, administrer ça me fait chier.

Hey choupette taper "svnadmin create" c'est pas plus du boulot d'admin que "git init".

Sur ce plonk, j'ai l'impresion que ton cerveau devient demeuré quand il est confronté à SVN…

Ainsi va le monde.

Et dieu inventa les méthodes agiles et la discussion avec le client plutôt que la confrontation.

L'intérêt du client s'est pas de se retrouver avec 100 features pourries. Si on prend la peine de discuter et négotier avec lui, on arrive à lui expliquer ce que coûte chaque chose et il peut faire ses choix. Il sera très content avec 60 features qui marchent parfaitement comme il le désire plutôt qu'une grosse merde.

on livre le code, en disant au client "vous aurez la doc plus tard", et plus tard, on bâcle la doc.

Ah non c'est pas livrer une feature ca. C'est produire du caca. Livrer une feature c'est quand toutes les tâches liées à sa définition sont finies et que le client l'accepte.

En pratique, sur des vrais systèmes, le changement à un peu plus d'impact sur la pile logicielle que ca.

D'une part dans le code réseau, d'autre part les IP on s'en sert un peu partout comme identifiant et ca remonte très très loin dans les chaines de traitement et d'analyse. J'ai des exemples de processus distribués qui utilisent entre autre les 32 bits d'une IPv4 pour créer un identifiant unique. Pris isolément ca se résoud toujours mais analyser toute la chaîne ca demande du boulot et basculer bêtement comme tu le dis peut faire très mal.

Après ca aurait du être fait il y a longtemps…

C'est marrant comme tu arrives à mélanger tout et n'importe quoi et à avoir un vision à géométrie très variable:

• Tu parles soudainement d'utilisateur débile alors qu'on parle de dev. Un SCM c'est l'outil de base d'un dev.
• Tu donnes des avantages à git qui n'existent pas. Ton coup de *.pyc il existe aussi avec git. git init . && git add . te donne exactement la même chose qu'un svn import et les solutions sont exactement les mêmes.
• Il ne doit surtout pas lire la doc ni comprendre un bête svnadmin. Pourquoi il comprendrait git init et la structure de git ?
• Il est tellment bête qu'il ne comprend que vaguement co/ci/log par contre il est capable de faire des rebase interactifs & co et d'en comprendre le conséquences. Comment dire ?

Tu es d'une objectivité rare. Le problème n'est pas de donner un conseil sur un outil. C'est de dire des conneries sur un autre.

Franchement vous me faites bien rigoler avec ces soit disant problème insurmontables qui se resolves en moins de 3 secondes. C'est vraiment pas les problèmes que vous soulevez qui sont bloquant ou feraient choisir un SCM plutôt qu'un autre. Et tu noteras que je ne recommande à aucun moment Subversion, par contre je sais m'en servir comme des autres.

Premier souci : il faut utiliser des chemins absolus.

C'est vrai sauf que ce que tu oublies c'est que le chemin absolu tu ne spécifie qu'une fois… au checkout.

si on veut/doit vraiment déplacer le référentiel, on peut toujours faire repointer la copie de travail vers le nouvel emplacement, mais c'est long.

Celle là c'est du même accabit que le "c'est long pour créer un repo". svn switch --relocate et basta. C'est exactement le même type d'opération que tu fais quand un projet migre de serveur ou que tu veux ajouter une nouvelle branche distante dans un DVCS.

Pour le reste tu as raison. Mais dans la vraie vie d'une part tu balances tes repos à un endroit et tu les déplaces plus jamais. Et d'autre part avec un DCVS tu mets pratiquement toujours un dépot de référence accessible en ssh même en bossant tout seul pour pouvoir bosser depuis n'importe machine. Ton path codé en dur tu l'as aussi au git remote add et tu le modifieras tout aussi aisément en cas de besoin.

Après ce sont des outils, chacun utilise celui qui semble avoir le plus approprié.

C'est une blague ?

Tu as une commande à exécuter: svnadmin create. Et c'est de toute facon ce que tu fais sur le serveur quand tu instancies un repo.

svnadmin create /path/to/myrepo
svnimport myproject file:///path/to/myrepo/trunk -m "Initial import"

Voilà fini. Le reste c'est le workflow classique.

Le fait que file:// est un protocole supporté est documenté depuis le début soit bientôt 13 ans. C'était extactement a même chose avec CVS.

Tu es au courant que tu peux très bien avoir un dépôt Subversion local ?

La vraie question c'est pourquoi c'est ou ca serait cradingue ?

À chaque fois que tu arrives avec un truc cradingue c'est que t'as raté un truc dans ton dev et ta gestion du dev. Il n'y a aucune raison qu'il y ait plus que la feature sur laquelle tu es en train de bosser qui soit un peu moche. Et elle n'a plus aucune raison d'être moche dès que tu l'as fini. Si c'est pas le cas il faut que tu identifies mieux tes bloques fonctionnels, que tu les définisses et que tu les finisses plutôt que de t'éparpiller et te retrouver du caca partout. Il faut vraiment avoir la force de tirer le signal d'alarme et se recentrer aussitôt.

En même temps si tu construits brique fonctionnelle par brique fonctionnelle y'a pas de raison que ça soit pété de bug à n'importe quelle étape ni que tu introduises de régression. Ta phase de QA elle a lieu au moment où tu implémentes chaque feature. Une fois fini tu peux passer à autre chose sans perdre ton temps plutôt que d'avoir un bazaar sans nom en permanence car 'c'est une alpha'.

Après des bugs tu en trouveras toujours. Mais y'a bug et bug.