El Titi a écrit 3940 commentaires

Oui sauf qu'avec toutes ces tergiversations, on n'a toujours pas vu un cas où la "commutation de patchs aurait ce comportement attendu.

Surtout, ce que tu as décrit (et que j'ai complété, c'est plutôt moi qui l'ai tendu le piège) intervient très rarement dans un process GCL digne de ce nom (à base de PR par exemple)

Pour l'instant, donc à part un cas purement théorique, je ne vois pas l'intérêt de changer d'outil si les avantages se limitent à ça.

Lorsqu'on vous demande un seul exemple concret, vous ressassez la théorie, l'auteur me renvoie aux "tutoriaux" et sans vouloir vous vexer, c'est carrément la disette:
https://www.google.fr/search?q=pijul+tutorial&oq=pijul+tutorial

En python, on appelle ça le "duck typing" :)

https://www.europe1.fr/politique/baisse-des-impots-contreparties-au-rsa-les-propositions-de-lr-pour-la-sortie-du-grand-debat-3873434

c'est que tu crois qu'on ne souhaite pas aider les pauvres.

Comme c'est mignon. Il se sent visé. Quand on est pauvre, on n'a pas besoin de charité Une - double humiliation- mais de tunes

Paye tes impôts, arrête de te plaindre d'en payer trop et la collectivité se chargera de les aider sans les contreparties que TOI tu veux.

C'est amusant car Zenitram et moi même avons maintes fois répété notre soutien au revenu universel réel sur ce site. Donc bon pour l'homme de paille on repassera.

Oui mais pas pour les mêmes raisons. Les vôtres, ce sont plutôt celles là:
https://www.contrepoints.org/2014/04/28/164437-un-argument-libertarien-pour-le-revenu-de-base

Bref pour virer tout le reste.

Mais tu devrais savoir que quand t'es pauvre, tu ne dois t'accorder aucun plaisir dans la vie car les moralisateurs de tout poil (mais tendance conservateur/cul bénis et fils à papa quand même) te tombent dessus.

• Picoler? fais gaffe tu deviens alcolo et "Ils" payent ta sécu
• Bien bouffer? Eux se payent des belles entrecôtes de 1kg maturées au resto, une fois par semaine, mais toi, arrête de te plaindre de bouffer de la merde de steack haché du LIDL et mets toi aux légumes. C'est bon pour ta santé … et leur porte-monnaie
• Cloper? cf. Picoler
• Baiser? Sans capote? T'as pensé à la planète ? Et c'est encore eux qui vont payer les allocs de tes mioches. Par contre dans la famille "Le Quesnoy", on ne se prive pas et on vote à droite pour que la politique d'arrosage familiale batte son plein. Si on peut rajouter quelques petites clauses pour tacler les familles de "racailles" des banlieues qui sont plus d'autres "confessions", c'est du bonus. Idiocracy inside.
• Tu peux pas payer de capotes, bin tu baises pas et pis c'est tout !
• Habiter à la campagne et venir au taf en bagnole ? T'as pensé à la planète ? Tu prends les transports en commun comme tout le monde. Pas eux bien sûr. Eux, ils habitent en plein centre et rejoignent le "bureau" à pince ou en vélo chez les bobos. T'as qu'à faire comme eux après tout ? Mais pour toi ça sera plutôt les HLMs de la zone, qu'ils ont encore la bonté de te subventionner. "Meeeerde quoi" (Coluche revient). Par contre faire passer le dossier par dessus la pile pour la petite nièce du 3 pièces avec une terrasse de 50 m dans le quartier étudiant parce qu'on connait la directrice, ça passe crème.
  

C'est pour ça que le Revenu Universel ne leur plait pas.
Il est versé de manière IN-CON-DI-TIO-NELLE. Et ça, ça les emmerde grave.
Ne plus te donner la charité, te faire la leçon et se sentir bouffis d'orgueil, l'élite

y a quand même un moment où il faut arrêter de prendre ses propres clients pour des connards.

Moi j'ai pété ma télécommande Free et je me suis installé l'appli sur mon tel pour pas passer à la caisse.
A chaque fois que j'allume ma box, je me tape une pub de 30s alors que je paye 40 euros/mois

Free, c'était pas l'opérateur alternatif dans la Vibe icitte, à la base ?

En attendant, le 1er projet open-source qui attire le + de contributeurs sur Github s'appelle Visual Studio Code et même Eclipse à intégré Intellisense.

La M$ bashing ça serait pas un combat d'arrière garde par hasard ?

C'est aussi à comparer avec mon PC perso sous Linux (auparavant Debian et en ce moment KDE Neon), dont je suis sûr qu'il a dû planter au moins une fois dans sa vie, mais je ne m'en souviens plus.

C'est cet ordi que tu as transformé en serveur FTP avec 3 distros Linux en share local ?

Tout ce que tu décris en terme de réorganisation est possible avec le rebase de Git.

Si j'essaie de comprendre ce que que tu exprimes:
Avec une vision "ensembliste" des patchs, on peut ré-agencer comme on le souhaite. La souplesse et la consistance seraient au rendez-vous car tout ceci est "mathématiquement" prouvé. Soit!

Le fait de ne pas ré-appliquer les commits (cherry-pick) est un plus car il conserve l'identité des patchs. Ok. (J'imagine que tu réarranges le graphe des patches en modifiant les arcs).

Pourtant, tu ne nies pas que seuls les patchs produits en // commutent. J'ai vraiment du mal à comprendre.

Par ailleurs, une petite critique au passage sur la documentation (Je sais que c'est encore en version alpha):
D'une manière générale, elle mélange les concepts et l'interface.
En tant qu'utilisateur, le format du repo m'importe peu (https://pijul.org/manual/format.html) . Par contre, voir à quoi ressemble la sortie d'une commande comme "add" "status" ou "log" m'apporterait.

pijul pull --from-branch A --to-branch B a1 A1 a2 A2 a3 A3
Là, tu inclues les ids de commits. Tu voulais peut-être écrire:

pijul pull --from-branch A --to-branch B a1 a2 a3
Nous sommes en local dans le même repo.
La doc de "pull" indique que la commande concerne la synchronisation avec des repo distants
https://pijul.org/manual/reference/pull.html. Le pull prend en charge la fusion aussi ?

D'autres choses m'interrogent (on peut mettre ça sur le compte de la maturité du projet , j'imagine).

• Quid de la séparation entre la synchro (fetch) et la mise à jour du workspace (merge)? Parfois c'est utile de ne pas recourir à un "git pull" et procéder en 2 temps.

• Comment tagguer une version ? Je lis dans la FAQ que ce n'est pas implémenté. Et surtout que les perfs risquent de s'en ressentir (O(n) vs O(1) pour git). De douloureux souvenirs s'éveillent en moi, ancien utilisateur de Clearcase et de SVN.

• Qu'en est-il du .gitignore ? Je me vois mal être obligé de préciser moi-même explicitement tous les fichiers à versionner. Est-ce que l'option --recursive du add en tient compte ?

Je ne vais pas te donner les exemples avec des diffs (mais tu ne me les donne pas non plus pour Git).

Ce n'est pas moi qui essaie de mettre en avant les atouts de mon projet. Un peu de pédagogie serait bienvenue. Les dépêches défilent et il n'est toujours question que de "théorie". Même si je comprends que tu préfères t'investir sur le projet, le temps d'écrire un tutoriel aurait largement été compensé par celui que tu passes à répondre ici ou sur reddit.

Je précise que ceci n'est pas une attaque.

Oui, c'est là qu'on atteint les limites de Git. Essentiellement, l'unique algorithme disponible (contrairement à ce qu'on nous vend) est le 3 way merge et dans certaines situations, déterminer le contributeur de base peut conduire à des cas tordus. Parfois, se baser dessus n'incombe pas le comportement attendu.

Si l'on reprend ton exemple et que -comme dans la vraie vie où l'on a décidé de ne pas livrer un changeset pour une release donnée, car la feature n'était pas prête- l'on l'intègre par la suite, on peut avoir quelques surprises :

   /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 -\ -- a4 -> A4 -------\
  /                                       \                    \
O ---- b1 -> B1 -- b2 -> B2 -- b3 -> B3 --> AB --> ABC --> BC-- ?
  \                                             /
   \-- c1 -> C1 -> c2 -> C2 -------------------/

Quel est le contributeur de base ici ? A3 ? ABC ?
Il y a quelques chances que le futur merge considère que la suppression des commits A(1,2,3)= BC soit retenue dans le merge automatique et qu'on ne retrouve pas ces commits que l'on voudrait intégrer.

Un "excellent/magique" VCS permettrait de lever un conflit ou tout au moins de préciser explicitement cette intégration.
J'attends toujours l'exemple concret qui montrerait que Pijul s'en sortirait mieux. J'attends aussi qu'on me démontre que la gymnastique intellectuelle que l'on doit appliquer afin de comprendre les cas où l'outil ne se comporterait pas comme on serait en droit de l'attendre, vaudrait de s'y investir.

En attendant, la bonne pratique, que tu "insinues" alambiquée est de ne pas intégrer les features non complètes et plutôt de merger depuis (ou rebaser sur) le trunk régulièrement pour se tenir à jour. On appelle ça: le feature branching.

Au pire, on constate les dégâts rapidment (vive la CI) et l'on reconstruit une branche bien propre à base de rebase interactifs.

Dans "la vraie vie", on aurait plutôt quelque chose de ce genre:

   /-- a1 -> A1 -- a2 -> A2 -- a3 -> A3 --- a4 -> A4 --\
  /                                     /               \         \
O ---- b1 -> B1 -- b2 -> B2 -- b3 ---> B3 ---> BC --------->ABC
  \                                             /
   \-- c1 -> C1 -> c2 -> C2 -------------------/

Bref, "dans la vraie vie" ton cas n'existe quasiment JA-MAIS

Si il faut plus d'une commande, fouiller dans les bonnes pratiques, chercher sur le net pour résoudre une question aussi triviale, alors git (ou autre VCS) a un problème. Il s'agit ici uniquement d'appliquer sur l'état ABC le patch inverse du composé de a1; a2; a3.

git revert AB^1
Afin de bien sélectionner le diff de droite.

Autre question ?

Si Alice décidait d'écrire En voici du sur la première ligne, et Bob décidait d'écrire Et ron et ron au lieu de Et patati et patata, alors Alice et Bob pourraient appliquer leurs deux patchs dans n'importe quel ordre, ça donnerait le même résultat

Désolé je ne saisis toujours pas. Lorsque tu parles de commuter des patchs en //, tu veux dire dans le cas d'un rebase ?
Par exemple, si les 2 rebasent chacun de leur coté ? (un criss cross rebase ?)
Avec git, on obtient aussi le même résultat. Je ne vois toujours pas l'intérêt de cette commutation.

En te lisant, je suis resté commun con.

Ah, les innombrables prémisses et projets dérivés de Papyrus.
Même pour pondre un modeleur qu'on peut mettre entre les mains de non techos sans metter la main à la pâte, on n'y est pas encore.
https://wiki.eclipse.org/Papyrus_for_Information_Modeling

Tu parles de la congélation du modèle au fur et à mesure qu'il se complexifie ?

Entre autres.
Aussi du fait que dès que tu enrichis ton modèle dérivé tu dois presque inévitablement retoucher le modèle parent à la main aussi vu que le premier porte plus de sémantique. C'est uen des motivation du MDA. On fait que du top down parce que le reverse est toujours incomplet. Ca devient vite fastidieux.
Tout est expliqué là.
https://www.amazon.com/MDA-Explained-Architecture%C2%BF-Practice-Promise/dp/032119442X

Pour la bière, si tu es sur sophia anti polis pourquoi pas :)

Sur Toulouse, mais ça ma m'arrive d'aller faire un tour du coté de la route des crêtes ;-)
Plus de messagerie privée depuis longtemps sur DLFP

Une bonne part de mes critiques rejoignent cet article.

http://www.theenterprisearchitect.eu/blog/2009/06/25/8-reasons-why-model-driven-development-is-dangerous/

et de ce commentaire:
https://softwareengineering.stackexchange.com/a/55698

Surtout concernant la gestion de conf, lorsque tu construis des chaines de transformation de modèles c'est un cauchemar. Ca ne scale pas. Les outils de merge dédiés n'aident pas (Le problème est déjà pa simple pour du code alors imagine pour des fichiers structuré comme le XMI. PAs facile de rendre consistant et atomique un changement réparti (un modèle est un graphe au final)

Ensuite le manque de sémantique d'un modèle (qui est intrinsèquement une abstraction) implique qu'il faut souvent plusieurs points de vue pour effectuer la transformation vers ton modèle/texte cible.
Assurer cette cohérence est complexe et contre productive (Je ne parle même pas de générer des comportements dynamiques)

…

Je n'ai pas saisi ta remarque précédente ni trop cette question.
Tu parles du MDA, du MDSD ?

Et ca serait un peu long de développer. Sauf si tu me payes une bière :)
Tu connais un peu la spec de l'OMG ?

D'expérience (j'ai bossé sur un projet de déploiement d'une approche MDE pendant plusieurs années) les problèmes sont nombreux et vraiment le Model Driven est aux antipodes des méthodes agiles.

Les seuls usages qui sont encore utiles selon moi sont:

• Soit de partir de modèles exprimés dans un DSL textuel et par transformation "Model to Text" générer un artéfact et jeter le modèle à la poubelle.
  Lorsque c'est bien fichu on appelle … le scaffolding ou …la compilation

• Soit comme déjà évoqué, enrichir suffisamment ton code pour faciliter la rétro-ingénierie à des fins documentaires et éventuellement, refactorer ton code pour aller vers l'architecture cible toujours en bottom up.

L'approche top down est une fausse bonne idée et le roundtrip au delà d'un certaine limite est quasi impossible.

La Hype est bien retombée. Il suffit de voir les tracks modeling à l'EclipseCon pour s'en rendre compte.

Bonjour,

Je suis peut-être ici le seul ignare mais j'ai un peu du mal à saisir cette arithmétique des patchs car je ne trouve nul part dans la doc la définition de ces patchs que Pijul manipule.

Pour moi un patch, (hormis la syntaxe du diff pour un cas simpliste), c'est
file.c:
+1, "blabla"

et mon fichier file.c contient:

blabla

si je rajoute:
file.c:
+1, En voilà du
+3, Et patati et patata

J'obtiens

En voilà du
blabla
Et patati et patata

Si je commute les patchs, j'obtiens

blabla

Et patati et patata

Pourrais-tu donner un exemple concret d'un patch avec Pijul ?
Parce que A et B ça ne me parle pas du tout.

Après avoir réinventé les workspaces séparés du repo, le lock exclusif de fichiers pour certains type non mergeable (comme les images ou les storyboards), le stockage des gros objets dans un format de sérialisation différent en dehors de l'historique, tout ça grâce à Git LFS,
… simplement parce que tout le monde utilise git en centralisé, gageons qu'ils vont avoir la bonne idée d'homogénéiser les types de fichier en créer des type manager pour gérer le merge/la comparaison /et le stockage des fichiers qui ont leur propres spécificités:
https://www.ibm.com/support/knowledgecenter/en/SSSH27_9.0.1/com.ibm.rational.clearcase.cc_ref.doc/topics/type_manager.htm

Encore un petit effort et on aura bientôt les vues dynamiques pour la CI et on pourra enregistrer la recette de fabrication des objets dérivés (le version de chaque fichier impliqué dans le build d'un objet) et on optimisera les builds entre différentes branches en réutilisant ces objets dérivés mis en cache.

Encore un petit effort et il vont nous mettre une db pour optimiser le stockge de tout ça à coté.

Encore un petit effort et après avoir épluché toutes les solutions bancales (submodules, subtree, …) pour gérer plusieurs repos dans la même vue logique et qui faisaient finalement la force de Bitkeeper il vont réinventer les config spec ou leur équivalent Perforce.

Encore un effort et git évoluera vers un modèle décentralisé plutôt que distribué ou chaque site distant aura la maîtrise sur certaines branches plutôt que de confier ça à un seul intégrateur (https://www.ibm.com/support/knowledgecenter/es/SSSH27_7.1.1/com.ibm.rational.clearcase.cc_ms_admin.doc/c_mstrshp_branch.htm). Et aussi parce que les forges (non distribuées elles) ont complété ce modèle incomplet avec des garde-fous sur les branches (webhook) pour pallier tout ça. (Le modèle méritocratique à la Linux en entreprise y'en a qui l'ont déjà vu sérieux ?). Et puis parce que bon les hooks coté client … voilà

Et on se dira qu'en fait plutôt que de se faire chier à gérer un simple cache d'historique (le D de DVCS) explicitement, on aurait pu utiliser un vrai cache qui n'oblige pas à cloner 1 repo de 5 Go qui t'oblige à faire des contorsions quand on se prend ça:
https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed

Et on réinventera Perforce ou Clearcase en new gen.

Welcome back to the future :)

A oui j'oubliais Git n'est pas un un outil de gestion de conf juste un "content manager" qui disaient !

Et dire qu'on est même pas vendredi.

Les transformations M2M (model 2 model) font aussi partie de la galaxie "Eclipse Modeling" ainsi que la génération de texte à partir de ton modèle (M2T) comme par exemple ton fichier de mapping ORM.
https://www.eclipse.org/modeling/transformation.php

L'ennui de cette approche et la principale raison pour laquelle le MDSD (Mode Driven Software Development) a échoué est que cette approche est top down. Ton modèle et ton code se retrouvent à un moment désynchronisé et il n'y a intrinsèquement pas de moyen resynchroniser ton modèle.

C'est pour ça que la notion de "Living Documentation" se retrouve dans tous les concepts liés aux approches agiles y compris pour le DDD.

Dans le BDD (Behaviour Driven Development), tes spécifications son exécutables. Ce couplage implique que tout changement de spec, couvert pas des tests, doit être aligné dans le code si nécessaire et à l'inverse un changement de code qui casse les tests indique soit un bug ou implique une maj de tes specs.
La documentation est toujours à jour.

Le DDD soutient ce principe puisque le métier est directement transcrit dans le code.
La vidéo Youtube que je t'ai pointée est très instructive car elle reprend ce principe à tous les niveaux et y apporte des solutions pratiques.
(Doc utilisateur, archi, specs, …)

En conclusion disposer d'une représentation de ton métier avec un modèle basé sur les concepts DDD pourquoi pas ?
Mais toujours en respectant les principes agiles, il est plus pertinent d'adopter une approche bottom-up par rétro-ingénierie à partir du code (le réel) quitte à enrichir ce code avec des annotations par exemple. Et on repart du code pour faire évoluer le modèle.
Tu peux aussi pratiquer du sketch modeling à l'ancienne comme base comparative mais toujours en évitant la tentation de regénérer le code (top down).

Le livre et la vidéo de l'auteur détaillent vraiment bien toutes ces pratiques

Ce n'est pas de l'UML justement.

Ca part d'une implémentation du MOF (https://en.wikipedia.org/wiki/Meta-Object_Facility) dans la spécification de l'OMG pour construire des "Domain Specific Modeling Languages" directement, par opposition aux "General Purpose Modeling Languages" dans lequel s'inscrit UML.
Tu reconstruis ton propre langage directement à partir d'un méta-modèle.
Avec UML; il faut restreindre la sémantique du langage avec des profils et les outils sont souvent moins adaptés pour ce genre de cas d"usages et il faut plus recourir au code
Papyrus (https://www.eclipse.org/papyrus/) s'inscrit dans cette démarche

Sirius adopte la stratégie inverse. Il part de l'Ecore (l'implémentation du MOF pour Eclipse) pour construire ton propre langage et te permet de générer tout le tooling nécessaire (éditeurs, palettes, query, …)

Ces 2 projets s'appuient sur le même cœur, le projet Eclipse Modeling: https://www.eclipse.org/modeling/

Tu peux aussi définir des DSL textuels grâce au même outillage et donc disposer de point de vue différents sur le même modèle:
https://www.eclipse.org/modeling/textual.php

Je ne connais pas d'autres alternatives opensource pour couvrir ce genre de besoins hors du monde Eclipse.

Et pour alimenter la polémique
http://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/

Si tu veux vraiment te lancer dans l'aventure de la modélisation DDD, tu peux peut être jeter un coup d'oeil à Sirius qui est métamodeleur et te permet de créer ton propre DSL graphique.
https://www.eclipse.org/sirius/

Il y'a quelques projets qui peuvent t'inspirer sur le "markeplace"
https://github.com/ObeoNetwork

Je ne suis pas certain de ce à quoi l'auteur fait référence mais cela est peut-être lié à l'éternel débat "Anemic" vs "Rich Domain Model" et l'utilisation de frameworks qui ont tendance à s'écarter des fondamentaux de l'approche objet comme Spring Data par opposition au DDD.

https://martinfowler.com/bliki/AnemicDomainModel.html

https://blog.pragmatists.com/domain-driven-design-vs-anemic-model-how-do-they-differ-ffdee9371a86

Dans le monde Java, par exemple un framework comme Axon encourage une approche Domain Driven.

Complément:
Un livre à prix libre sur la documentation vivante (incluant DDD):
https://leanpub.com/livingdocumentation

et la video d'une conf de l'auteur:
https://www.youtube.com/watch?v=Tw-wcps7WqU

Un livre gratuit pour introduire les concepts:
https://www.infoq.com/minibooks/domain-driven-design-quickly

Sinon tootella:
https://github.com/heynickc/awesome-ddd

Ah bin merde alors.
Avec ta gueulante plus haut c'était pas plus libre que Blabalacar.

Là c'est pas assez pour Môssieur.
C'est plus libre que Blablacar du coup non ?

Ca devient hyper chiant de te voir la ramener sur tous les journaux pour montrer que tu as la plus grosse.

T'as pas une vraie vie ?

Et si mon ton ne te plait pas, relis tes posts hargneux et pète un coup.

C'est vrai que, aussi candide qu'on soit, poster un projet/une idée auquel/à laquelle on croit de bonne foi sur DLFP et se faire démonter la gueule avec le Boyard en chef en tête de file, ça donne envie de répondre.

Les gars de la monnaie libre ont compris la leçon aussi je pense.

Tout le monde a compris que ce site est devenu un panier de crabes a peu près au même niveau qu'AgoraVox

D'ailleurs, on le mesure au dynamisme du site aujourd'hui