il y a quand même une commande git rerere, ça ne s'invente pas !
1 point pour toi. Je commence à me laisser séduire.
Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, …
Darcs a eu ses chances et est passé aux oubliettes.
Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
J'ai bien ma petite idée mais les tiennes m'intéressent.
De mon coté, je vois déjà le fait que l'implémentation était basée sur un langage assez abrupt et confidentiel. Rust est plus populaire, il me semble.
L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.
Le modèle de données a évolué et les algos aussi de ce que je comprends.
Mais il reste ce point évoqué dans votre FAQ: le “exponential merge problem”. Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
Ceci ne remet-il pas en question tout l'édifice ?
Pourrais-tu développer un peu ?
Question subsidiaire: Un point important pour son adhesion est l'interopérabilité.
J'ai cru voir qu'il y avait des scripts d'import depuis Git mais je crois que ce qui rassurerait les early adopters serait plutôt un genre de pont qui permettrait de se synchroniser avec un repo git tout en jouant avec Pijul en local (un peu comme git-svn).
Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?
Tu as intégré ce nouveau paradigme et tu as confiance en lui car il s'appuie sur une théorie mathématique dans laquelle tu baignes.
C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
Pour beaucoup, le modèle conceptuel derrière Mercurial (des sous graphes connexes en quelque sorte) interpellait les afficionados de Git.
Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
Mais même si c'est mal nommé le terme de "branche" est couramment admis.
En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
Dans les mal nommés "branching patterns", on parle de branchement par release.
Avec un DVCS on peut imaginer 2 moyens pour maintenir des variantes:
- S'appuyer sur des forks (un par variante) auquel cas la notion de branche perd tout sens
- Faire cohabiter les 2 variantes dans un même repo. Il faut donc mettre en place un mécanisme pour les matérialiser.
Le modèle de base de Hg correspond au premier et perturbe les utilisateurs git (alors que git peut aussi le supporter en conservant une branche unique).
Donc oui ce n'est pas "absolument" indispensable mais confortable tout de même et fort heureusement Pijul le supporte.
Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.
les cas "à la marge", pour reprendre un de tes commentaires).
Désole de t'avoir piqué, mais ce cas est vraiment marginal en effet. Je ne l'ai rencontré que sur 2 projets durant toute ma "longue" carrière dans une boîte de 500 devs et pourtant le support Git m'incombe.
En revanche, si comme tu l'évoques les rebase qui s'effectuent une fois sur 2 avec un conflit sont évités. Là ça devient intéressant. Et c'est ça qu'on trouve un peu "magique"
Certes, mais ça ne veut pas dire qu'on réarrange quoi que ce soit. Au contraire, on a une structure de données où on sait prouver que l'ordre n'importe pas, et donc que deux dépôts avec le même ensemble de patchs, même dans des ordres différents, sont équivalents sans qu'on n'ait besoin de "réarranger".
Ok, cette base de donnée qui s'appuie sur un b-tree peut-être.
Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?
ont été soit ignorés, soit commentés d'un "ok, Pijul le fait gratuitement, mais avec Git je peux faire la même chose en tapant cinq commandes, après avoir passé une heure à lire la doc et à régler des trucs à la main".
Ce que tu ne saisis pas je crois c'est que les exemples se sont cantonnés à du ASCII Art.
Et comprends aussi que nombre d'entre nous sont à l'aise avec cet outil pour un usage quotidien.
Tu m'as immédiatement asséné que seuls les patchs // commutent.
C'est toi qui est le mieux à même d'illustrer les exemples différenciant, pour convaincre.
Nous sommes tous désireux d'adopter un outil qui s'appuie sur un modèle théorique solide, à condition qu'il démontre qu'il répond à nos besoins et qu'il nous apporte du mieux.
Au passage, dans cette doc sur Darcs ce sont les patchs séquentiels qui commutent, il semblerait. Ca plus les graphes de lignes: Votre modèle semble bien différent, même s'il s'en inspire.
Ca n'aide pas non plus à la compréhension.
Je crois que c'est moi qui vais m'y coller sur ce tuto parce que visiblement c'est un dialogue de sourds
Il n'y a pas de DAG de commits dans Pijul, juste des ensembles de patchs.
C'est pourtant écrit dans la doc existante des dizaines de fois, je l'ai redit dans mon commentaire plus haut, c'est partout dans toute notre communication, et dans les tutoriels contribués par d'autres. Je doute que des tutoriels supplémentaires changent quoi que ce soit.
Je n'ai pas parlé de commit mais de graphe de patchs. Et il me semble bien que c'est le cas non ?
Je cite:
Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
- de nouveaux sommets et arêtes
- et de changements de statut d'arêtes.
Pourquoi les branches et commits dessinés en ascii art constituent des exemples concrets, et ma réponse non ?
Après je suis désolé de t'importuner, mais pour moi un exemple concret, ça serait plus un tutoriel qui compare des actions git et pijul sur un repo avec un vrai fichier exemple et permettrait de montrer comment leur comportement diffère.
Bref, exactement ce que Jehan a développé.
Et sans vouloir te vexer, question tutoriels, Google ne m'a pas beaucoup aidé en ce sens.
La seule chose que tu as fait c'est nier un problème que même Linus ne nie pas et auquel il propose une solution pour contourner les limites de git
Je me cite:
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.
En revanche ile est clair que les méthodes de projets modernes (agiles) atténuent grandement les désagréments liés à ces problématiques de fusions.
Que ce soit le Continuous Delivery, Scrum ou autres. Elles s'appuient sur la création de branches par fonctionnalité (feature branches) et l'intégration via des pull requests, ce qui limite leur durée de vie dans le temps.
Hormis les considérations GCL (pardon, de versionning) elles apportent d'autres avantages (A/B testing, …).
Bref, dans la vraie vie, ces scénarios que vous décrivez n'existent qu'à la marge et ne justifient pas un changement d'outil.
Mais je ne doute pas que Pijul a d'autres arguments et nous démontrera ses vertus. Il a pour lui de beaux arguments (Rust, une UI épurée, la jeunesse, une théorie que j'aimerais voir concrètement appliquée, …)
la rigueur intellectuelle ne semble pas être une priorité pour certains.
En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
C'est d'ailleurs une des forces de Git. Je me souviens de tous ces innombrables VCS (systèmes de contrôles de version :) qui se targuaient de gérer mieux que quiconque le"rename tracking" en le rendant explicite et qui se sont ramassés sur les cas tordus.
Avant que tu ne m'objectes de parler chinois, je te renvoie ici (cherche le terme Merge file renames): https://en.wikipedia.org/wiki/Comparison_of_version-control_software
En gros, comment se débrouille un merge entre 2 branches lorsque le fichier est renommé ?
Il faut détecter que le fichier a été renommé pour appliquer le merge plutôt que de créer un nouveau fichier.
Certains VCS conservent la trace des renommages explicites.
Git a fait un choix différent. Il utilise une de ces "heuristiques" tant décriées par certains.
Il compare simplement le contenu du fichier et considère qu'il a été renommé si le contenu est semblable.
Oh mon dieu, quelle horreur! Ca marche pour 95% des cas mais ce n'est pas mathématiquement prouvé.
Tu peux même ajuster le taux de recouvrement pour tes besoins (find-renames: https://git-scm.com/docs/git-merge)
Seulement voilà, les autres VCS partisans de la stratégie explicite s'y sont cassés les dents parce que dans les cas tordus, ça foire. Au hasard (SVN, Mercurial, Bazar, Monotone, …)
Il y a même eu un wiki pour répertorier tous ça. Il est down maintenant mais un petit gars a essayé de le sauver. https://github.com/tonyg/revctrl.org
Honnêtement, si tu penses réellement m'avoir tendu un piège, de quelque forme qu'il soit, il faudra que tu me montres où il se trouve.
Je me corrige:
(et que j'ai complété, c'est plutôt moi qui ME LE SUIS tendu le piège)
C'est moi qui ai développé ton graphe pour montrer le cas qui pose pb, il me semble.
Maintenant, si tu acceptes d'utiliser un ton à peine moins condescendant, on pourrait peut-être reprendre le fil de la conversation et tu pourrais peut-être répondre à la question au lieu de tourner autour du pot:
on n'a toujours pas vu un cas où la commutation de patchs aurait ce comportement attendu.
Si on prend aussi le temps de répondre, ce n'est pas forcément pour "démonter" Pijul. Bien au contraire. Et je serai le 1er à m'enthousiasmer pour le challenger qui enterrera Git (Plusieurs pourraient en témoigner ici)
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.
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.
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.
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 :
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:
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.
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.
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
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.
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 !
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
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
Reçu, Capitaine Modon!
Je vais essayer de mettre de l'eau dans mon vin.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
1 point pour toi. Je commence à me laisser séduire.
Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, …
Darcs a eu ses chances et est passé aux oubliettes.
Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
J'ai bien ma petite idée mais les tiennes m'intéressent.
De mon coté, je vois déjà le fait que l'implémentation était basée sur un langage assez abrupt et confidentiel. Rust est plus populaire, il me semble.
L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.
Le modèle de données a évolué et les algos aussi de ce que je comprends.
Mais il reste ce point évoqué dans votre FAQ: le “exponential merge problem”. Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
Ceci ne remet-il pas en question tout l'édifice ?
Pourrais-tu développer un peu ?
Question subsidiaire: Un point important pour son adhesion est l'interopérabilité.
J'ai cru voir qu'il y avait des scripts d'import depuis Git mais je crois que ce qui rassurerait les early adopters serait plutôt un genre de pont qui permettrait de se synchroniser avec un repo git tout en jouant avec Pijul en local (un peu comme git-svn).
Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 6.
Tu as intégré ce nouveau paradigme et tu as confiance en lui car il s'appuie sur une théorie mathématique dans laquelle tu baignes.
C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
Pour beaucoup, le modèle conceptuel derrière Mercurial (des sous graphes connexes en quelque sorte) interpellait les afficionados de Git.
Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
Mais même si c'est mal nommé le terme de "branche" est couramment admis.
En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
Dans les mal nommés "branching patterns", on parle de branchement par release.
Avec un DVCS on peut imaginer 2 moyens pour maintenir des variantes:
- S'appuyer sur des forks (un par variante) auquel cas la notion de branche perd tout sens
- Faire cohabiter les 2 variantes dans un même repo. Il faut donc mettre en place un mécanisme pour les matérialiser.
Le modèle de base de Hg correspond au premier et perturbe les utilisateurs git (alors que git peut aussi le supporter en conservant une branche unique).
Donc oui ce n'est pas "absolument" indispensable mais confortable tout de même et fort heureusement Pijul le supporte.
Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Désole de t'avoir piqué, mais ce cas est vraiment marginal en effet. Je ne l'ai rencontré que sur 2 projets durant toute ma "longue" carrière dans une boîte de 500 devs et pourtant le support Git m'incombe.
En revanche, si comme tu l'évoques les rebase qui s'effectuent une fois sur 2 avec un conflit sont évités. Là ça devient intéressant. Et c'est ça qu'on trouve un peu "magique"
C'est un début, mais c'est sur la partie branche qu'on souhaiterait plus de matière.
Allez, ne disperse pas ton énergie.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 0.
Ok, cette base de donnée qui s'appuie sur un b-tree peut-être.
Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?
Ce que tu ne saisis pas je crois c'est que les exemples se sont cantonnés à du ASCII Art.
Et comprends aussi que nombre d'entre nous sont à l'aise avec cet outil pour un usage quotidien.
J'ai essayé de te donner un début d'exemple avec un fichier concret un peu comme ce qui est décrit ici pour Darcs:
https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory
Tu m'as immédiatement asséné que seuls les patchs // commutent.
C'est toi qui est le mieux à même d'illustrer les exemples différenciant, pour convaincre.
Nous sommes tous désireux d'adopter un outil qui s'appuie sur un modèle théorique solide, à condition qu'il démontre qu'il répond à nos besoins et qu'il nous apporte du mieux.
Au passage, dans cette doc sur Darcs ce sont les patchs séquentiels qui commutent, il semblerait. Ca plus les graphes de lignes: Votre modèle semble bien différent, même s'il s'en inspire.
Ca n'aide pas non plus à la compréhension.
Je crois que c'est moi qui vais m'y coller sur ce tuto parce que visiblement c'est un dialogue de sourds
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 1.
Je n'ai pas parlé de commit mais de graphe de patchs. Et il me semble bien que c'est le cas non ?
Je cite:
https://linuxfr.org/news/pijul-controle-de-version-et-theorie-des-patchs-version-0-12#comment-1768959
aka graggles:
https://jneem.github.io/merging/
Après je suis désolé de t'importuner, mais pour moi un exemple concret, ça serait plus un tutoriel qui compare des actions git et pijul sur un repo avec un vrai fichier exemple et permettrait de montrer comment leur comportement diffère.
Bref, exactement ce que Jehan a développé.
Et sans vouloir te vexer, question tutoriels, Google ne m'a pas beaucoup aidé en ce sens.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
Je me cite:
En revanche ile est clair que les méthodes de projets modernes (agiles) atténuent grandement les désagréments liés à ces problématiques de fusions.
Que ce soit le Continuous Delivery, Scrum ou autres. Elles s'appuient sur la création de branches par fonctionnalité (feature branches) et l'intégration via des pull requests, ce qui limite leur durée de vie dans le temps.
Certains protagonistes vont même plus loin en prônant le "trunk dev" (une branche unique) pour encourager l'intégration continue (au sens propre), principe fondateur de l'agilité.
https://martinfowler.com/bliki/FeatureBranch.html
Ils proposent d'autres techniques pour aborder les developpement // comme
https://www.martinfowler.com/articles/feature-toggles.html
https://martinfowler.com/bliki/BranchByAbstraction.html
Hormis les considérations GCL (pardon, de versionning) elles apportent d'autres avantages (A/B testing, …).
Bref, dans la vraie vie, ces scénarios que vous décrivez n'existent qu'à la marge et ne justifient pas un changement d'outil.
Mais je ne doute pas que Pijul a d'autres arguments et nous démontrera ses vertus. Il a pour lui de beaux arguments (Rust, une UI épurée, la jeunesse, une théorie que j'aimerais voir concrètement appliquée, …)
A suivre
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 1.
Pardon, c'est un terme assez usuel dans l'industrie logicielle: https://fr.wikipedia.org/wiki/Gestion_de_configuration_logicielle
qui fait même l'objet de normes:
https://blog.ansi.org/2017/05/configuration-management-iso-100072017/
https://www.boutique.afnor.org/standard/ieee-828/configuration-management-in-systems-and-software-engineering-note-approved-2012-02-06-ieee/article/800191/us044653
En effet, ceux qui ne restent pas dans la théorie s'intéressent au pragmatisme et préfèrent adopter des outils qui font le job.
C'est d'ailleurs une des forces de Git. Je me souviens de tous ces innombrables VCS (systèmes de contrôles de version :) qui se targuaient de gérer mieux que quiconque le"rename tracking" en le rendant explicite et qui se sont ramassés sur les cas tordus.
Avant que tu ne m'objectes de parler chinois, je te renvoie ici (cherche le terme Merge file renames):
https://en.wikipedia.org/wiki/Comparison_of_version-control_software
En gros, comment se débrouille un merge entre 2 branches lorsque le fichier est renommé ?
Il faut détecter que le fichier a été renommé pour appliquer le merge plutôt que de créer un nouveau fichier.
Certains VCS conservent la trace des renommages explicites.
Git a fait un choix différent. Il utilise une de ces "heuristiques" tant décriées par certains.
Il compare simplement le contenu du fichier et considère qu'il a été renommé si le contenu est semblable.
Oh mon dieu, quelle horreur! Ca marche pour 95% des cas mais ce n'est pas mathématiquement prouvé.
Tu peux même ajuster le taux de recouvrement pour tes besoins (find-renames: https://git-scm.com/docs/git-merge)
Seulement voilà, les autres VCS partisans de la stratégie explicite s'y sont cassés les dents parce que dans les cas tordus, ça foire. Au hasard (SVN, Mercurial, Bazar, Monotone, …)
Il y a même eu un wiki pour répertorier tous ça. Il est down maintenant mais un petit gars a essayé de le sauver.
https://github.com/tonyg/revctrl.org
Je me corrige:
C'est moi qui ai développé ton graphe pour montrer le cas qui pose pb, il me semble.
Maintenant, si tu acceptes d'utiliser un ton à peine moins condescendant, on pourrait peut-être reprendre le fil de la conversation et tu pourrais peut-être répondre à la question au lieu de tourner autour du pot:
Si on prend aussi le temps de répondre, ce n'est pas forcément pour "démonter" Pijul. Bien au contraire. Et je serai le 1er à m'enthousiasmer pour le challenger qui enterrera Git (Plusieurs pourraient en témoigner ici)
Tiens pour le fun:
https://linuxfr.org/users/minimock/journaux/git-a-fete-ses-10-ans-hier
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 1.
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
[^] # Re: Effectivement
Posté par El Titi . En réponse au journal Windows est enfin prêt pour le desktop . Évalué à -4. Dernière modification le 09 mai 2019 à 19:03.
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
[^] # Re: Effectivement
Posté par El Titi . En réponse au journal Windows est enfin prêt pour le desktop . Évalué à -3.
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.
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.
[^] # Re: Effectivement
Posté par El Titi . En réponse au journal Windows est enfin prêt pour le desktop . Évalué à 8. Dernière modification le 09 mai 2019 à 18:26.
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.
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
[^] # Re: Effectivement
Posté par El Titi . En réponse au journal Windows est enfin prêt pour le desktop . Évalué à 1.
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 ?
[^] # Re: Mais il va rester quoi à Linux ?
Posté par El Titi . En réponse au journal Windows est enfin prêt pour le desktop . Évalué à 3.
C'est cet ordi que tu as transformé en serveur FTP avec 3 distros Linux en share local ?
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2. Dernière modification le 06 mai 2019 à 14:16.
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
pijul pull --from-branch A --to-branch B a1 a2 a3
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 ?
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.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
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 :
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:
Bref, "dans la vraie vie" ton cas n'existe quasiment JA-MAIS
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2.
Autre question ?
[^] # Re: Patchez moi !
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 2. Dernière modification le 01 mai 2019 à 21:46.
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.
[^] # Re: Exemples concrets?
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 7.
En te lisant, je suis resté commun con.
[^] # Re: Domain Driven "Design"
Posté par El Titi . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 2.
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
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
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
[^] # Re: Domain Driven "Design"
Posté par El Titi . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 3.
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)
…
[^] # Re: Domain Driven "Design"
Posté par El Titi . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 3.
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.
# Patchez moi !
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3. Dernière modification le 29 avril 2019 à 20:59.
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:
si je rajoute:
file.c:
+1, En voilà du
+3, Et patati et patata
J'obtiens
Si je commute les patchs, j'obtiens
Pourrais-tu donner un exemple concret d'un patch avec Pijul ?
Parce que A et B ça ne me parle pas du tout.
[^] # Re: Et pour les fichiers binaires ou du moins autres que texte?
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
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.
[^] # Re: Domain Driven "Design"
Posté par El Titi . En réponse au journal Conception pilotée par le domaine ou Domain-driven design (DDD). Évalué à 2.
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