Question migration cvs -> git tout ça tout ça.
Si j'ai un seul gros dépôt, ça pue
Si j'ai un dépôt par module cvs, comment je gère les dépendances entre projets, comment je fais du git log ou du git bissect multi-repos (un projet étant composé de plusieurs modules), etc etc

Parce que jusqu'à présent, c'était moi le chef ?
 
edit: bon, ok, c'est pas forcément un très bon argument...

Tu peux pas vraiment faire du git log ou du bisect en multi-repo.

 
Pourquoi ça pue de faire un seul dépot ?

Si si, avec les submodules, par contre c'est pas si simple que ça à prendre en main pour un débutant. Il faut bien lire la doc et comprendre comment ça fonctionne.

Après pour le bisec il faut surement rajouter la commande "git submodule update --init --recursive" dans le script de bisection pour mettre à jour chaque submodule à la version associée à celle du commit du superprojet.

Tout le monde semble dire que git scale mal sur les gros dépôts    

dites les gros, en webgl y'a moyen de faire tourner un shader sur un framebuffer qui aurait qu'un seul canal de couleur ?
j'ai essayé avec un buffer GL_LUMINANCE, mais ça s'est pas bien passé:  "the internalformat of the attached texture is not color-renderable"
 
Y'a moyen de faire passer un shader sur un truc qui est pas color-renderable?

Preusm sur footixet.
 
http://reho.st/https://pbs.twimg.c [...] .jpg:large

 
https://www.khronos.org/registry/gl [...] ure_rg.txt  ptet

 
j'attend avec impatience la mascotte de l'équipe de france

je l'ai pas dans mon navigateur.  
apparemment y'a moyen de récupérer le z buffer en texture, il faut que je regarde ça en détail, parce qu'au final c'est ça mon info.

Les mecs, ils ont confiance.
 
Notre vénéré N+2 nous a demandé au moment du rachat de chiffrer le coût du renommage (dans le code, les docs, le paramétrage, etc..) dont acte.
 
Maintenant, il s'agit de le faire! (l'ancienne maison mère a donné une deadline au delà de laquelle son nom ne doit plus apparaître aux yeux des clients)
 
Problème : comment on renomme? Nous, on a rien dit là dessus (au moment du chiffrage on connaissait de toutes façons pas le nouveau nom de la boite)
 
Lors de la présentation, on a proposé de remplacer partout "AncienNom" par "NouveauNom", normal quoi.
 
Mais le N+2, brillant, nous a dit :  
 
"ouais, non c'est nul, si jamais on rechange de nom faudra tout refaire, je veux un truc générique. Je veux pas d'initiales ou de nom en dessous de 8 caractères pour éviter les collisions ( déjà avec un nom de root package en fr, stuveux, on est pas mal niveau collisions), et je veux que ça soit signifiant."
 
Il a proposé "X-productline" (en remplaçant X par l'initiale réelle).. On lui a dit que "-" est interdit dans un nom de package, une variable d'environnement ou autre, et que d'une manière générale, les caractères spéciaux pour ce genre de truc c'est un peu la misère.
 
Donc, il se décharge en nous demandant de proposer qqchose qui ne soit pas "NouveauNom", ni "NN". Et vite, siouplé, hein!

Et je remarque que t'as soigneusement ignoré de mentionner git log, qui est spécialement foireux avec les submodules

Voilà donc git bisect en interactif, avec les submodules ça marche plus, t'es obligé de te souvenir de mettre à jour tes submodules à chaque step, et quand tu utilise bisect run t'es obligé d'ajouter un wrapper pour le faire.

 
Si ta texture a comme internal format DEPTH_COMPONENT tu appelles glCopyTexImage2D et ça copie le depth buffer oué

t'es de mauvaise foi "git log" utilise "git diff" et donc avec l'option d'activée sur le diff on a une vue détaillée dans le log

et sinon avec gitk en graphique c'est encore mieux !

oui enfin c'est pas si lourd que ça à mettre en place c'est une ligne, c'est dommage car ce n'est pas automatique mais c'est pas killer non plus.
 
https://github.com/HaxeFoundation/h [...] git-bisect

S'toi mauvaise foi.
 
T'es obligé d'utiliser -p donc pour avoir le log du submodule dans le log du projet t'es obligé d'afficher tous les diffs (ou de postfiltrer), et le log du submodule est embeddé dans le message du parent sous un format vraiment discutable, c'est pas de l'interleaved propre.

Ça double juste le nombre de commande par étape, et si tu t'en souviens pas t'as un step foiré.

Bon, sinon, d'habitude, je ne lis pas les blog posts de LinkedIn, mais celui-la est sympa:
Ten Stupid Rules That Drive Great Employees Away
 
"Capable people don't want to put up with being treated like children or criminals, so they leave to go work somewhere else." <-- pourquoi je me tire.

et bim  
http://www.lemonde.fr/politique/ar [...] 23448.html

Tout le monde semble dire que git scale mal sur les gros dépôts    

masklinn en fait il faut le provoquer pour en faire sortir des choses intéressantes

Mais le N+2, brillant, nous a dit :

"ouais, non c'est nul, si jamais on rechange de nom faudra tout refaire, je veux un truc générique. Je veux pas d'initiales ou de nom en dessous de 8 caractères pour éviter les collisions ( déjà avec un nom de root package en fr, stuveux, on est pas mal niveau collisions), et je veux que ça soit signifiant."

 
J'ai déjà fait l'erreur de complexifier prématurément des process avant de vérifier si ça posait réellement un problème, finalement j'ai l'impression qu'il vaut mieux avoir
quelques secondes de plus pendant certains commandes/téléchargements plutôt que de courir après les lignes de commandes atypique et les outils qui supportent la fragmentation.
 
Accessoirement, "gros dépôts" c'est un peu comme"big data", personne est d'accord pour savoir à partir de quand c'est gros et on se plante souvent quand on croit être concerné,
mais bon c'est pas vraiment étonnant dans une industrie majoritairement masculine...

Accessoirement, "gros dépôts" c'est un peu comme"big data", personne est d'accord pour savoir à partir de quand c'est gros et on se plante souvent quand on croit être concerné,
mais bon c'est pas vraiment étonnant dans une industrie majoritairement masculine...

Ca me fait tjrs rire quand on voit des posts de blog d'untel qui utilise Cassandra/Spark pour avouer à la fin qu'il n'a que 50 ou 100Go en base.

offshoringandownsizingoperation, c'est générique, réutilisable, fait plus de 8 chars, et c'est signifiant.

Les mecs, ils ont confiance.
 
Notre vénéré N+2 nous a demandé au moment du rachat de chiffrer le coût du renommage (dans le code, les docs, le paramétrage, etc..) dont acte.
 
Maintenant, il s'agit de le faire! (l'ancienne maison mère a donné une deadline au delà de laquelle son nom ne doit plus apparaître aux yeux des clients)
 
Problème : comment on renomme? Nous, on a rien dit là dessus (au moment du chiffrage on connaissait de toutes façons pas le nouveau nom de la boite)
 
Lors de la présentation, on a proposé de remplacer partout "AncienNom" par "NouveauNom", normal quoi.
 
Mais le N+2, brillant, nous a dit :  
 
"ouais, non c'est nul, si jamais on rechange de nom faudra tout refaire, je veux un truc générique. Je veux pas d'initiales ou de nom en dessous de 8 caractères pour éviter les collisions ( déjà avec un nom de root package en fr, stuveux, on est pas mal niveau collisions), et je veux que ça soit signifiant."
 
Il a proposé "X-productline" (en remplaçant X par l'initiale réelle).. On lui a dit que "-" est interdit dans un nom de package, une variable d'environnement ou autre, et que d'une manière générale, les caractères spéciaux pour ce genre de truc c'est un peu la misère.
 
Donc, il se décharge en nous demandant de proposer qqchose qui ne soit pas "NouveauNom", ni "NN". Et vite, siouplé, hein!

Mais sinon, c'est pas un peu une quasi-obligation d'utiliser le nom de domaine inversé de la boite ? d'autant plus que ça évite automatiquement les collisions.

C'est juste une convention, et c'est le nom du projet (qui peut être "namespacé dans" le nom de la boite ou de l'organisation, mais pas obligatoirement)

y'a moyen de la binder en uniform dans un shader plutôt ?

 
Bah je pense que oui. Tu fais un glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, depthTexture);   et après layout (binding = 0) uniform sampler2D depthBuffer;

Aaaah, mais comme on a des winners parmi les managers dissaïdorz, ils ont décidé que le nom du projet est OBLIGATOIREMENT le nom du produit, qui lui peut changer.
 
Donc au final, on a toujours un truc qui peut changer dans les noms de packages.
 
 

bah si mais bon.
 
 
Enfin, ça c'est ce qu'ils voudraient dans leur monde idéal à eux. Dans les faits c'est différent (déjà parce que les noms de produits ont un "-" au milieu)
 
Ils exigent aussi que tous les produits aient le même versionnage.
Ce qui fait qu'on eu à un moment des branches de dev identiques, au nom de version Maven près.
 
Bon, on a fini par leur faire entendre raison en consommant plein de temps à maintenir - et releaser - ces putains de versions inutiles, mais ça a pris vachement de temps.
 

 
Accessoirement, "gros dépôts" c'est un peu comme"big data", personne est d'accord pour savoir à partir de quand c'est gros et on se plante souvent quand on croit être concerné,
mais bon c'est pas vraiment étonnant dans une industrie majoritairement masculine...

Des fois j'ai un peu le moral en berne à force de rester au chômage, c'est sympa de m'aider à relativiser