Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".
Je ne comprends absolument pas le sens de cette partie de ton commentaire. On va reprendre l'historique de nos échanges, ce sera plus clair.
pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés
Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.
À moins que j'ai complètement la berlue ou que j'ai perdu la raison, c'est bien toi qui as parlé de graphe orienté et je ne vois toujours pas en quoi c'était en termes profanes. Que ta boulangère ne sache pas ce qu'est un graphe orienté, personne ne l'a nié, mais là n'était pas la question. Le fait est que pijul aussi gère un graphe orienté d'états successifs, la différence entre les deux outils ne se situe pas à ce niveau là. Que ce graphe soit une catégorie (et c'est peut être cette notion que tu appelais « concept mathématique relativement avancé »), on s'en fout un peu dans le fond, raison pour laquelle j'ai ensuite écrit :
Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.
Il va de soi que par mon tout le monde, j'entendais tout programmeur (ce qui exclus ta boulangère, à moins qu'elle ne programme dans ses moments de loisir), c'est-à-dire les seules personnes susceptibles de discuter des entrailles de ce genre d'outils.
Reprenons la distinction entre pijul et git.
les deux graphes colorés un peu différents
D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process".
Là je ne comprends pas trop non plus. Les deux graphes en question expose la même situation que celle dans le lien du tout premier commentaire de pamaury, et à ce moment tu ne semblais pas avoir compris. Pourtant ils disent la même chose. En revanche tu continues avec :
J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur
sauf que ton exemple ne correspond pas du tout à cette situation. Ton code illustre deux branches qui divergent et qui rentrent en conflit quand on les fusionne : ce n'est pas du tout ce qu'illustrent les graphes colorés. Ils illustrent deux stratégies qui ne génèrent pas nécessairement de conflit mais avec deux résultats différents pour git et un seul avec pijul. Ainsi, lorsque tu écris :
dans tous les cas on arrivera sur le même état Q
Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit.
tu n'as toujours pas compris. Non, dans un cas réel il n'y a pas nécessairement conflit et pijul arrivera bien toujours dans le même état Q quelque soit le chemin pris dans le graphe, c'est-à-dire quelque soit la stratégie utilisée. Assurément, bien que git fusionne sans se plaindre (il n'y a pas de conflit) le code ne compilera pas, mais cela demandera un travail supplémentaire au développeur ou alors il faudra utiliser un workflow conditionné par l'outil. On est là dans le même genre de problématiques qu'entre typage statique ou typage dynamique : pour éviter les runtime error (un code qui ne compile pas après fusion) il faut prendre ses précautions.
Pour la suite :
là où, par construction, elle est automatiquement satisfaite dans pijul
Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).
Si ! cette propriété est automatiquement satisfaite par construction dans pijul. Cf. mon point précèdent. Ton exemple de code de gestion d'utilisateur est hors propos pour parler de cette spécificité de pijul.
De plus, personne, mais alors vraiment personne, n'a prétendu qu'il existait un outil de fusion magique qui résout les conflits tout seul. Là n'est pas la question, ni le problème que cherche à résoudre pijul.
Pour la question des patchs indépendants :
Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.
La question n'était pas là mais celle-ci : dans un tel cas, git crée-t-il automatiquement deux branches distinctes dans son graphe d'états pour se faciliter le travail ?
La problématique de fiabiliser la production logicielle m'intéresse réellement.
Je veux bien te croire, mais tu ne sembles pas disposer à faire l'effort d'essayer de comprendre ce que les autres écrivent. Dans un autre journal où j'essayais d'illustrer l'analogie stricte entre typage statique et démonstration de théorèmes, tu m'avais également lu de travers. À moins que tu ne considères pas le typage statique comme relevant de la problématique de fiabiliser la production de logicielle. Une partie du système qui gère les lignes automatiques du métro parisien a été développé selon une telle méthodologie, et il est difficile de remettre en cause pas les faits sa fiabilité.
Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot !
Si git te satisfait pleinement, pourquoi changer d'outil ? Pijul offre certes des avancés (ne serait-ce que celle de fournir une spécification à la notion de fusion), mais pas celles qui semblent correspondre à tes attentes :
Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.
Pijul ne le résout évidemment pas, personne n'a jamais dit le contraire, il n'y a rien à prouver. Tu l'as dit toi même : aucun logiciel ne viendra jamais le résoudre, le problème est indécidable, c'est même pire, il est informulable (le problème n'est pas l'absence de procédure de décision, mais qu'on ne peut même pas l'exprimer formellement).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Pourquoi du théorie des patch c'est bien
Posté par kantien . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 4.
Je ne comprends absolument pas le sens de cette partie de ton commentaire. On va reprendre l'historique de nos échanges, ce sera plus clair.
Tu as commencé par écrire
ce à quoi je te réponds
tu réagis ensuite par
et je réponds à cela par
À moins que j'ai complètement la berlue ou que j'ai perdu la raison, c'est bien toi qui as parlé de graphe orienté et je ne vois toujours pas en quoi c'était en termes profanes. Que ta boulangère ne sache pas ce qu'est un graphe orienté, personne ne l'a nié, mais là n'était pas la question. Le fait est que pijul aussi gère un graphe orienté d'états successifs, la différence entre les deux outils ne se situe pas à ce niveau là. Que ce graphe soit une catégorie (et c'est peut être cette notion que tu appelais « concept mathématique relativement avancé »), on s'en fout un peu dans le fond, raison pour laquelle j'ai ensuite écrit :
Il va de soi que par mon tout le monde, j'entendais tout programmeur (ce qui exclus ta boulangère, à moins qu'elle ne programme dans ses moments de loisir), c'est-à-dire les seules personnes susceptibles de discuter des entrailles de ce genre d'outils.
Reprenons la distinction entre pijul et git.
Là je ne comprends pas trop non plus. Les deux graphes en question expose la même situation que celle dans le lien du tout premier commentaire de pamaury, et à ce moment tu ne semblais pas avoir compris. Pourtant ils disent la même chose. En revanche tu continues avec :
sauf que ton exemple ne correspond pas du tout à cette situation. Ton code illustre deux branches qui divergent et qui rentrent en conflit quand on les fusionne : ce n'est pas du tout ce qu'illustrent les graphes colorés. Ils illustrent deux stratégies qui ne génèrent pas nécessairement de conflit mais avec deux résultats différents pour git et un seul avec pijul. Ainsi, lorsque tu écris :
tu n'as toujours pas compris. Non, dans un cas réel il n'y a pas nécessairement conflit et pijul arrivera bien toujours dans le même état Q quelque soit le chemin pris dans le graphe, c'est-à-dire quelque soit la stratégie utilisée. Assurément, bien que git fusionne sans se plaindre (il n'y a pas de conflit) le code ne compilera pas, mais cela demandera un travail supplémentaire au développeur ou alors il faudra utiliser un workflow conditionné par l'outil. On est là dans le même genre de problématiques qu'entre typage statique ou typage dynamique : pour éviter les runtime error (un code qui ne compile pas après fusion) il faut prendre ses précautions.
Pour la suite :
Si ! cette propriété est automatiquement satisfaite par construction dans pijul. Cf. mon point précèdent. Ton exemple de code de gestion d'utilisateur est hors propos pour parler de cette spécificité de pijul.
De plus, personne, mais alors vraiment personne, n'a prétendu qu'il existait un outil de fusion magique qui résout les conflits tout seul. Là n'est pas la question, ni le problème que cherche à résoudre pijul.
Pour la question des patchs indépendants :
La question n'était pas là mais celle-ci : dans un tel cas, git crée-t-il automatiquement deux branches distinctes dans son graphe d'états pour se faciliter le travail ?
Je veux bien te croire, mais tu ne sembles pas disposer à faire l'effort d'essayer de comprendre ce que les autres écrivent. Dans un autre journal où j'essayais d'illustrer l'analogie stricte entre typage statique et démonstration de théorèmes, tu m'avais également lu de travers. À moins que tu ne considères pas le typage statique comme relevant de la problématique de fiabiliser la production de logicielle. Une partie du système qui gère les lignes automatiques du métro parisien a été développé selon une telle méthodologie, et il est difficile de remettre en cause pas les faits sa fiabilité.
Si git te satisfait pleinement, pourquoi changer d'outil ? Pijul offre certes des avancés (ne serait-ce que celle de fournir une spécification à la notion de fusion), mais pas celles qui semblent correspondre à tes attentes :
Pijul ne le résout évidemment pas, personne n'a jamais dit le contraire, il n'y a rien à prouver. Tu l'as dit toi même : aucun logiciel ne viendra jamais le résoudre, le problème est indécidable, c'est même pire, il est informulable (le problème n'est pas l'absence de procédure de décision, mais qu'on ne peut même pas l'exprimer formellement).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.