Reprise du message précédent :

C'est du C

http://www.touilleur-express.fr/20 [...] ess-board/
 
le truc cool, c'est que tu mets en place ton workflow sans faire chier les autres.
 
Genre, tu as un projet open source, tu checkout les sources. Vu que c'est SVN, tu n'es pas autorisé à faire de commit. Donc en local, tu te retrouve bloqué à ne plus pouvoir versionner tes modifs. (ou sinon il faut te couper du SVN du projet et donc des updates)
 
Avec un DVCS, tu checkout, tu commit en local sans faire chier le projet open source Quand tu es content de tes modifs, tu fais un patch ou autre...  
Tu peux faire des branches du projet sur ton poste, etc

pas uniquement competent, mais passionné.
 et aussi une certaine mentalité, que nous n'avons pas: pas seulement faire un bon produit mais innovant et original (ce qui est pas notre cas non plus). Je trouve dommage de se contenter de faire du bug fix et courir apres les besoins du client alors que les devancer serait mieux

ich bin corporate  

Bien sur.

C'est beau....

 
le truc c'est que j'ai l'impression que je risque de devoir superviser des équipes de dev (j'ai rien trouvé encore, mais y'a toute une famille d'annonces où c'est latant : un poste à la jonction de l'univers suit / t-shirt )
 
donc j'essaye un peu de me remettre d'aplomb sur 2-3 sujets qui peuvent arriver dans la discussion : le but c'est pas de devenir un expert, mais de comprendre les enjeux

Maintenant qu'on sait que Linux est supérieur au reste faudrait qu'on trouve un autre sujet pour ce vendredi

 
PQ

 
ça demande aussi à ce que le client ait l'état d'esprit qui aille bien...y'a des clients qui vivent très mal le fait que l'idée ne viennent pas d'eux
 
après tu peux finasser sans le dire : quand j'étais en stage, on avait fini par implémenter de fait la gestion du multiprofil sans le dire au client, parce qu'en interne ça nous facilitait grandement la vie...le client voulait pas initialement, trop cher pour ce que ça apportait parait-il
 
un jour on l'a mit devant le fait accompli, en lui montrant tout ce qu'on a économisé comme temps en ayant la fonction, il nous a remercié d'avoir désobéi...

oh et si les gens arrêtaient de se faire la guerre et que tout le monde s'aimait et était honnête                

chuis chef d'équipe

mais pas les gitans quand meme

*CENSURE*

http://foundsf.org/images/2/25/Gay1$leather-slaves.jpg

c'est toi qui tiens la laisse?

 
Ah oui pour raconter des conneries bisounours derriere tu peux meme lui envoyer goatse

la vieille publicité mensongère, tu passes ta vie à te faire refuser des commits pour des merges triviaux, t'as des fichiers qui te font tout le temps chier, il dit qu'ils sont modifiés, mais tu vois pas la différence. Il faut faire un "checkout" pour faire un revert. Tu as 40 000 commandes tordues mais pas les moyens de les exploiter dans les plugins.

C'est une galère sans nom. Le seul vrai avantage c'est que t'as une copie de tout le repo sur tout les clients et du coup t'as moins peur que tout plante comme avec SVN.

Mais jamais ils prennent des vacances ?
http://www.leparisien.fr/flash-act [...] 030665.php

au début ça fera ça mais au bout d'un moment il deviendra plus facile de faire un commentaire de commit clair plutot que de te rappeler si t'es a fix 46 ou fix-47 et de te taper 4 refus de commit  

pq

variable global + context partagé = miserable failure

Outdated OS is outdated    

paul Graham c'est un peu le BHL du web technologique, même sans avoir lu ses écrits, c'est difficile de ne pas le connaitre.

euhhhhh ....
qu'est-ce que t'entend par la ? AMHA, apple est consumer centric a fond.

http://www.ericsink.com/entries/dvcs_dag_1.html
http://www.ericsink.com/entries/dvcs_dag_2.html

Il a fait quoi ?

Faire du bug fix et courir après le besoin client paye les salaires et les factures. Faire ce que conseille paul Graham peut te rendre riche ... sauf si tu te plante comme 95% de ceux qui font ça.

Ben tu vois même en ayant lu certains de ses écrits je le connaissais pas.

Par contre BHL c'est vrai, je sais qui c'est et j'ai jamais rien lu de lui

Il a dit qu'un iphone 4 est aussi performant qu'une Xbox ou qu'une PS2

Et il l'a prouvé.

Par contre tu sais qui est sa femme

Oui aussi. Mais j'ai jamais rien lu d'elle non plus.
 
 
 
wait...

Link ?

http://erictric.com/2010/08/12/id- [...] at-60-fps/

C'est toi qui a voulu utiliser git  

Spécial harko: http://www.engadget.com/2010/08/13 [...] id-market/

Question utopique : Vous avez l'équivalent du "projet du vendredi aprem" de chez Google dans vos boites respectives ?

non, mais y'a des trucs que j'ai trouvé louche dans la présentation.
Genre ils n'ont plus aucun problème de merge...alors que j'ai réussi à en avoir un il y a deux jours alors que je suis le seul dev sur mon projet
Et dans les logs, ils n'ont plus que des commits par activité, contrairement à SVN (alors que, à part en utilisant je pense la queue de patch, je ne vois pas comment c'est possible...ou j'ai pas compris)

Pour les commandes, sur mercurial, en tout cas, c'est pareil que svn, avec pull et push en plus...

Ce qui m'a vraiment plus dans la présentation par contre, c'est l'indépendance du flux de travail & bisect (pour retrouver la version qui plante)

ben HG marchait pas, j'ai utilisé git

 
1/ ah pas du tout non...jobs a bloqué pendant des années le concept de tablette parce que la techno correspondait pas à la vision qu'il avait du truc...si il avait été consumer centric il aurait sorti une merde avec le logo Apple dessus, et il en aurait vendu...
Apple c'est la boite designer-centric : ils misent avant tout sur le design et l'ergonomie de leurs produits, et Jobs a prouvé pendant ces 20 dernières années qu'il poussait pour SA vision du design, quitte à être incompris, ou quitte à pas être le market leader (ce qui va se passer pour l'iPhone vs Android). Jobs l'a dit en interview d'ailleurs : il s'en fou d'etre le leader en PDM, il veut faire des produits bien designés, et occuper une niche rentable en les vendant
 
2/ merci je regarde
 
3/ oui carrément...
 

 
OK donc si je vous suis, passé le hype c'est un peu la meme merde qu'un bon vieux SVN des familles quoi...

c'est un poil mieux, mais ça n'a rien de révolutionnaire, et c'est encore plus compliqué.

On a pas le même concept de "consumer centric" là

Ah bah oui, on a vraiment pas le même concept

Pas d'accord du tout. Par contre niveau tooling, c'est clairement pas ça. Et comme t'as environ un concept de plus, ya des gens qui sont tout perdus.

http://www.ericsink.com/entries/No_Great_Hackers.html
 
en crawlant un peu sur le lien de Mareek, je suis tombé là dessus : c'est une bonne réponse au truc de Graham posté par Uriel (ironiquement, le post est d'ailleurs une réponse à un truc plus vieux de Graham )

consumer centric c'est faire ce que veulent absolument les consommateurs
Apple n'est pas du tout une boite consumer centric : si ils avaient suivi les désirs de leurs clients, l'iPad serait sorti bien plus tot (et surement moins bon qu'il n'est aujourd'hui), idem les mac auraient plus d'options de configuration, etc...
 

le concept c'est la possibilité de merger les nodes a posteriori, c'est de ça dont tu parles ?
 
ce que je comprends pas, c'est que le merge, c'est la plaie des VCS (surtout si tu dev sur plusieurs branches en //)...hors finalement un DVCS ne t'en dispense pas une seule seconde (in fine t'es bien obligé de regrouper le code que tu veux releaser, donc tu DOIS merge), donc ça ne résoud en rien ce problème ?
 
y'a l'aspect distributed ensuite, mais bon dans le cadre d'une boite j'ai rarement vu tomber un serveur SVN donc je sais pas si c'est un truc intéressant à l'échelle d'une boite où tlm a accès au serveur en LAN
 
en fait j'essaye de comprendre quel problème ça résoud

 
il faut canoniser ce saint. C'est vrai qu'iTunes et quick time, ce sont des design parfaits  

Non, ça répond à des problématiques que SVN est incapable de répondre (indépendance du workflow, rien que ça...). Mais il y a des merdes que j'avais avec SVN, que j'ai toujours (conflit lors d'un merge). Et SVN est aussi plus simple à comprendre (quand personne ne vous fait un p'tit dessin )
 
L'indépendance des workflows, j'insiste dessus, mais vu ce qu'il est possible de mettre en place avec, il faut s'y pencher un peu
 
Si tu as envie de bosser comme avec SVN avec juste un repos central, tu peux.
Si tu as envie de commiter en local, que ce commit déclenche le build de ton projet sur ta machine et si tout est OK, alors ça pousse le commit sur le repos central, tu peux aussi
Si tu veux faire un fork d'un projet open source, tout en profitant des mises à jours du projet forker, tu peux

les DVCS ça ne résout absolument rien au niveau des merges. Si 2 mecs ont bossé sur le même fichier en même temps, c'est la même galère avec git ou SVN.
 le seul petit truc que ça change, c'est qu'en git t'as committé localement avant le merge, donc si tout plante ou que tu te chies, tu peux refaire ton merge.
 
Par exemple on a un fichier SQL de 6Mo qui traine dans les sources ( ), ben on prévient avant d'y toucher, parce qu'on sait que personne ne pourra le merger.

Ce n'est pas qu'il peut tomber, c'est qu'on peut t'interdire de commiter dessus.
 
exemple tout con : le merge d'une branche sur le trunk. Tu as plus le droit de commiter sur la branche ou le trunk avant la fin du merge. (soit 2 jours d'attente en moyenne )
 
avec mercurial, ils auraient mergé, et moi, j'aurais continué de commiter en local, tranquilou. Puis j'aurais poussé après.  
 
Alors que avec SVN, j'ai rien commité, j'ai fais des gros patchs que j'ai foutu sur le trunk, et j'ai fais un seul commit avec des modifs qui ont aucun rapport entre eux...

Perso je l'ai vu plusieurs fois mais y a toujours des backups + images locales si besoin. Passke bon, une boîte qui a un SVN sans backup régulier du repo, c'est bien fait pour sa gueule le jour où elle perd tout

Non, pas d'accord, le consommateur lambda est con comme un bol, c'est pas en l'écoutant que t'améliores sa vie. Une boite consumer-centric, c'est une boite qui veut améliorer la vie du consommateur, pas se faire un maximum de blé sur son dos (qui est ce que tu décris)

Non, c'est le push/pull, le fait de discuter entre repositories au lieu de juste discuter entre working copies via le repo central.

Le merge, c'est la plaie des VCS qui savent pas merger (qui se souviennent pas de leur historique, qui ne te gardent pas ton historique en branches parallèles, etc...)

Tu devras toujours merger si tu as 2 personnes qui bossent en parallèle, le but c'est de rendre l'opération plus simple et d'essayer d'éviter ses échecs

En dehors du fait que le réseau/le net/le serveur qui tombe ça m'est arrivé (ou une panne électrique si tu bosses sur un laptop), l'exemple "je bosse dans un avion" est utilisé non parce que c'est le plus gros avantage (c'en est très loin IMO) mais parce que tout le monde le comprend.

Je peux te filer une liste que j'ai posée sur reddit il y a un an ou deux, mais tu vas pas nécessairement intuiter les avantages mentionnés (blub toussa):

Accessoirement, ça fait genre 3 ans qu'on a commencé à parler de DVCS sur le topic, survoler l'histo pourrait te servir: http://forum.hardware.fr/forum2.ph [...] 0&filter=1

Après notes bien que les DVCS n'ont pas que des avantages. Mais pour autant que je sois concerné, pour des développeurs dans la grande majorité des contextes (partout en dehors des jeux vidéos, globalement), les DVCS sont largement supérieurs aux DVCS.

Bah ouais mais pendant qu'il est down ton repo, ben soit tu bosses plus soit tu sors un BBOM

Le consommateur manifeste une envie, mais il faut lui répondre par le remplissage d'un besoin. Les deux peuvent ne pas se ressembler.

Exemple :
- le consommateur veut pouvoir emmener sa chaine dans la rue pour ecouter de la musique dans la rue .
reponse  a lk'envie : ghetto blaster
reponse au vrai besoin : walkman

devinez lequel a gagné

Oui, voilà, faut pas lui donner ce qu'il demande donc (en général)