Il ne paraît pas déraisonnable d'inférer qu'on se fait plus facilement agressé en traînant dans Paris à pied après minuit qu'en allant au travail sur des routes du campagne vers potron-minet. Les données sur les agressions devraient donc être recoupées avec les mœurs pour obtenir des informations utiles
Et d'ailleurs, tu évites bien de te promener dans les endroits à risques dans lesquels tu te retrouverais en minorité, avec ton allure de petit bourgeois, n'est-ce pas Pierre-Mathieu ?
Tes moeurs ne sont donc pas si louables et tu devrais peut-être t'encanailler un chouia, voire même t'affubler de quelques "guenilles" pour te fondre dans la masse … en extrapolant … à peine … ton raisonnement.
A moins que la bonne interprétation ne fut que l'on doive respecter ton état, ta différence "hors norme des quartiers" sans "mais, mais, …"
De plus vous mettez dans le même panier les tares génétiques de naissance, et les orientation sexuelles conscientes et choisit faudrait pas exagérer.
Les gamins ne naissent pas se avec le Dc qui
La déviance (j'utilise ce mot à bon escient) intellectuelle des dégénérés "conscients" qui "croient" que ceux qui ne sont pas comme eux sont des suppôts du "Malin" aka les "culs bénis".
"Heureux les simples d'esprit, le royaume des cieux est à eux!"
T'as déjà ton billet, même si tes tares ne sont pas génétiques, encore que…
Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer foo--bar--1.0, l
Je m'ne souviens, c'était imbitable , avec du Perl en plus, je crois me souvenir :)
Chapeau en tout cas. Tu persévères dans les DVCS. Bientôt contributeur sur Pijul ? ;-)
Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks.
Oui, dès le début, c'est pour ça qu'ils ont trainé avant d'incorporer ce plugin.
Mais malgré tout, toutes les heads étaient logiquement liées (une branche est un sous-graphe connexe) alors qu'avec Git c'est la refspec (entre autres) qui assure cette correspondance.
Hormis la commmutation, Pijul est un peu semblable. Une "branche" (une variante) n'est qu'un ensemble de patchs et on n'a pas vraiment de trace de quel repo proviennent les patchs une fois intégrés, hormis l'auteur (et la signature GPG).
Je trouve ça élégant car c'est assez symétrique mais ça peut être un obstacle à son adoption auprès de utilisateurs habitués à Git.
tla (Tom Lord Arch) était déjà mourant à l'époque, je ne suis même pas sûr que Linus l'ait regardé.
Pour son usage, non.
Pour les concepts, Git s'en rapproche beaucoup plus et j'ai l'impression que Linus s'en est inspiré. Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.
(Après, je n'ai jamais vraiment creusé le fonctionnement de Bitkeeper, donc c'est peut-être de là que ça vient)
Monotone fonctionne à la manière de Hg. On a une unique branche qui à un instant donné et elle peut avoir plusieurs heads de manière indifférenciées.
Les bookmarks sont apparus bien après pour attirer des utilisateurs habitués à Git.
Après le 1er pull
C résoud un conflit entre A et B et introduit une dépendance dans ton set,on a: e2={C->(A,B); E->D}
avec:
C
toto.txt
a
b
Dans e3 (l'autre user, on introduit un nouveau changement F ("b" devient "tadaa"). On a e3={F->B} avec;
F:
toto.txt
tadaa
Lorsqu'on pull dans e2 à nouveau on se retrouve avec: e2={C->(A,B); E->D, F->B} mais pour ton algo qui conserve un graphe de ligne même si B est une dépendance de C et F il ne considère pas ça comme un conflit est reconstruit la snapshot (le workspace) globale en :
toto.txt
a
tadaa
Il n'a pas besoin de construit un nouveau commit (automatiquement généré) pour le coup ?
Git évidemment se vautre car il a 1 3 way avec comme
base:
(un commit antérieur à ceux qui ont introduit a et b résolu lors du 1er conflit qui peut contenir a ou b ou aucun des 2)
(par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit),
A a produit "a"
B a produit "b"
C a résolu le conflit en "c" par exemple et a été résolu dans e2
Si on reprend mon formalisme, la personne qui détient e3 est donc initialement dans l'état:
e3={B}
En introduisant un change sur les lignes de B, on modifie toujours la même ligne par exemple:
pour lui "b" devient "tadaaa"
Je correspond à ton exemple ici:
Maintenant, la personne qui a produit B continue à travailler, pour produire par exemple F (on pourrait dire que F change toutes les lignes introduites par B, et ne fait que ça).
On produit F avec "tadaa" à la place de "b"
Lorsqu'il recorde dans e3, il a : e3={B<-F}
et pas :
e3 = {B, F}
non ?
Après, si on incorpore dans e2 on a forcément un conflit à résoudre aussi e2={A<-C->B, D<-E, B<-F}
Je dois bien résoudre mon fichier qui contient actuellement "c" et il me demande de résoudre avec "tadaa"
(je vais changer la notation pour récursive dans les dépendances)
Il sera résolu en F avec "tutu"
e2={ D<-E, F->(B, C->(A,B)) }
Je vais essayer de le rejouer avec Pijul pour voir le résultat
et essayer de comprendre.
Je ne vois toujours pas le rapport avec rerere dans cet exemple mais je crois que je peux essayer d'en construire un autre. Je vais creuser.
Avec des noms sur les patchs, ça donne : si tu as deux patchs A et B qui sont en conflit (par exemple, A écrit "a" dans un fichier, et B écrit "b" au même endroit), tu peux produire un patch C qui résout ce conflit. N'importe qui qui a les deux patchs A et B va voir le même conflit (indépendamment des autres patchs qu'ils pourraient avoir, par exemple s'ils ont d'autres patchs D ou E). Et à partir du moment où tu as A, B, et C dans le même dépôt, ce conflit est résolu. Il ne reviendra pas (au revoir, git rerere!).
J'avoue que ça reste encore un peu flou, alors j'essaye de détailler.
Afin de lever toute ambiguïté, je te propose d'utiliser la terminologie suivante (Je sais que vous y réfléchissez encore et j'ai pas mal cogité et bidouillé de mon côté ;-) :
Toute branche au sens de Pijul est appelée ensemble car ce n'est ni plus ni moins que ça - un ensemble de patchs (change) atomiques et de séquences de patch (interdépendants et ordonnés) -.
Par exemple, si on a 2 sous-ensembles dans notre dépôt: e1={A} et e2={A, D<-E}.
Chacune de ces entités (unités de changement ou séquences) commutent entre elles. On a, de par la commutativité: {A, D<-E} == {D<-E, A} != {E<-D, A}
(Une séquence ne commute pas entre ses propre constituants mais commute avec les autres entités).
Jusque là, j'ai juste ?
Admettons que l'on incorpore un nouveau change ( pijul pull ) B dans e1 qui entre en conflit et que l'on doive évidemment le résoudre avant de l'intégrer ce qui donne C comme dépendance. ( pijul dependencies)
Si te je suis toujours, on obtient à présent: e1={A<-C->B}, e2={A, D<-E}
Si j'incorpore les changes de e2 dans e1 ( pijul pull e2), je me retrouve avec
e1={A<-C->B}, e2={A<-C->B, D<-E}
On n'a donc pas eu à ré-effectuer la résolution par nous-même.
C'est bien ça ?
Ce que j'ai du mal à imaginer par contre, c'est un cas où le git rerere ou même le fait de rejouer le même conflit serait nécessaire ici.
Sauf peut-être… si on a commencé à jouer avec des cherry-picks entre 2 branches de release. Et je ne vois pas non plus vraiment, dans quelles situations un rebase (vu en tant que suite de cherry-picks) redemanderait de ré-appliquer les mêmes conflits.
Mais je conviens que l'approche de Pijul est élégante et moins hasardeuse.
J'adhère totalement à ton discours sur la raison d'être d'une arme à feu (tuer) vs celle du P2P (partager des informations sans centralisation) et dont le piratage n'est qu'un usage détourné
Dommage que tu n'appliques pas le même raisonnement avec la sur la publicité dont l'objet est bien de faire connaître un produit. Dommage que fasses un glissement sémantique. Qu'elle soit "mensongère" n'est aussi qu'un usage détourné. La raison d'être de la pub n'est pas de "mentir" ou d'abuser le consommateur.
I’d say the main thing to expect before 1.0 could be one last format change to reduce the disk space usage, and handle large (possibly binary) files more easily. The patch format shouldn’t change, so there will be almost no disruption.
D'un point de vue algorithmique, tout se présente pour le mieux.
Mais malgré tout quelques inquiétudes que je ne semble pas être seul à partager.
Pour accomplir tout ça de manière déterministe, il semble qu'il faille redonder énormément d'informations.
Sincères félicitations, mais tout de même, 230 Mo de stockage pour 17 Mo de lignes de code ça fait quand même peur.
Je n'ose pas imaginer un dépôt plus conséquent en terme de bande passante au niveau du clone.
Dans ma boîte, on a plusieurs projets de + de 1 Go (avec des binaires, certes) et Bitbucket est carrément à la ramasse avec un clone qui part en timeout.
Mais bon un dépôt de l'ordre de 200 Mo, c'est quand même assez fréquent.
J'espère sincèrement qu'il y a encore matière à optimiser, au moins pour le transport.
En tout cas, c'est déjà un sacré boulot d'accompli.
Ou tout simplement utiliser Pijul pour ses propres besoins et remercier les auteurs du projet
Merci aux auteurs de porter le flambeau du Git NG et en guise d'encouragement, je ne peux que citer son papa:
Does Git last forever, or do you foresee another revision control system in another 10 years? Will you be the one to write it?
Torvalds: I'm not going to be the one writing it, no. And maybe we'll see something new in ten years, but I guarantee that it will be pretty "git-like." It's not like git got everything right, but it got all the really basic issues right in a way that no other SCM had ever done before.
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)
[^] # Re: Pauvre Alan Turing
Posté par El Titi . En réponse au journal Agressions, insultes, harcèlement... Cinq mois de violences contre les LGBT en France. Évalué à -8. Dernière modification le 17 mai 2019 à 19:04.
Et d'ailleurs, tu évites bien de te promener dans les endroits à risques dans lesquels tu te retrouverais en minorité, avec ton allure de petit bourgeois, n'est-ce pas Pierre-Mathieu ?
Tes moeurs ne sont donc pas si louables et tu devrais peut-être t'encanailler un chouia, voire même t'affubler de quelques "guenilles" pour te fondre dans la masse … en extrapolant … à peine … ton raisonnement.
A moins que la bonne interprétation ne fut que l'on doive respecter ton état, ta différence "hors norme des quartiers" sans "mais, mais, …"
[^] # Re: Linuxfr est désormais un espace de diffusion proLGBT ?
Posté par El Titi . En réponse au journal Agressions, insultes, harcèlement... Cinq mois de violences contre les LGBT en France. Évalué à 0.
La déviance (j'utilise ce mot à bon escient) intellectuelle des dégénérés "conscients" qui "croient" que ceux qui ne sont pas comme eux sont des suppôts du "Malin" aka les "culs bénis".
"Heureux les simples d'esprit, le royaume des cieux est à eux!"
T'as déjà ton billet, même si tes tares ne sont pas génétiques, encore que…
[^] # Re: Intuitif
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 14 mai 2019 à 23:17.
Je m'ne souviens, c'était imbitable , avec du Perl en plus, je crois me souvenir :)
Chapeau en tout cas. Tu persévères dans les DVCS. Bientôt contributeur sur Pijul ? ;-)
Oui, dès le début, c'est pour ça qu'ils ont trainé avant d'incorporer ce plugin.
Mais malgré tout, toutes les heads étaient logiquement liées (une branche est un sous-graphe connexe) alors qu'avec Git c'est la refspec (entre autres) qui assure cette correspondance.
Hormis la commmutation, Pijul est un peu semblable. Une "branche" (une variante) n'est qu'un ensemble de patchs et on n'a pas vraiment de trace de quel repo proviennent les patchs une fois intégrés, hormis l'auteur (et la signature GPG).
Je trouve ça élégant car c'est assez symétrique mais ça peut être un obstacle à son adoption auprès de utilisateurs habitués à Git.
[^] # Re: Intuitif
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.
Pour son usage, non.
Pour les concepts, Git s'en rapproche beaucoup plus et j'ai l'impression que Linus s'en est inspiré. Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.
(Après, je n'ai jamais vraiment creusé le fonctionnement de Bitkeeper, donc c'est peut-être de là que ça vient)
Monotone fonctionne à la manière de Hg. On a une unique branche qui à un instant donné et elle peut avoir plusieurs heads de manière indifférenciées.
Les bookmarks sont apparus bien après pour attirer des utilisateurs habitués à Git.
[^] # Re: Intuitif
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ésolé, je voulais écrire que: "Il (Monotone) se rapproche plus de Mercurial, qu'il a inspiré (Mercurial).
Mais Merci pour le rafraîchissement d moire au sujet de Monotone et Arch.
[^] # 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.
Tu bloubes :D
https://linuxfr.org/users/benoit_in/journaux/pijul-un-nouveau-gestionnaire-de-source#comment-1714073
[^] # Re: Intuitif
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.
Tu es sûr pour monotone ?
Il se rapproche quand même plus de Mercurial qui l'a inspiré.
Il me semblait que c'était Arch de Tom Lord.
[^] # Re: Intuitif
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.
Il y avait Bitkeeper aussi.
En plus c'est un open source. A merde, ça s'est venu 10 ans après !
[^] # 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é à 2.
Ok je crois que je je commence à piger.
Au départ on a
Après le 1er pull
C résoud un conflit entre A et B et introduit une dépendance dans ton set,on a:
e2={C->(A,B); E->D}
avec:
Dans e3 (l'autre user, on introduit un nouveau changement F ("b" devient "tadaa"). On a
e3={F->B} avec;
Lorsqu'on pull dans e2 à nouveau on se retrouve avec:
e2={C->(A,B); E->D, F->B} mais pour ton algo qui conserve un graphe de ligne même si B est une dépendance de C et F il ne considère pas ça comme un conflit est reconstruit la snapshot (le workspace) globale en :
Il n'a pas besoin de construit un nouveau commit (automatiquement généré) pour le coup ?
Git évidemment se vautre car il a 1 3 way avec comme
base:
(un commit antérieur à ceux qui ont introduit a et b résolu lors du 1er conflit qui peut contenir a ou b ou aucun des 2)
ours:
theirs:
Je vais tester tout ça.
Merci
[^] # 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é à 2.
Je m'excuse mais tu m'as perdu.
Pour rappel sur ton exemple:
A a produit "a"
B a produit "b"
C a résolu le conflit en "c" par exemple et a été résolu dans e2
Si on reprend mon formalisme, la personne qui détient e3 est donc initialement dans l'état:
e3={B}
En introduisant un change sur les lignes de B, on modifie toujours la même ligne par exemple:
pour lui "b" devient "tadaaa"
Je correspond à ton exemple ici:
On produit F avec "tadaa" à la place de "b"
Lorsqu'il recorde dans e3, il a :
e3={B<-F}
et pas :
e3 = {B, F}
non ?
Après, si on incorpore dans e2 on a forcément un conflit à résoudre aussi
e2={A<-C->B, D<-E, B<-F}
Je dois bien résoudre mon fichier qui contient actuellement "c" et il me demande de résoudre avec "tadaa"
(je vais changer la notation pour récursive dans les dépendances)
Il sera résolu en F avec "tutu"
e2={ D<-E, F->(B, C->(A,B)) }
Je vais essayer de le rejouer avec Pijul pour voir le résultat
et essayer de comprendre.
Je ne vois toujours pas le rapport avec rerere dans cet exemple mais je crois que je peux essayer d'en construire un autre. Je vais creuser.
[^] # Re: discussion
Posté par El Titi . En réponse au journal Markdown et Epub. Évalué à 10.
C'est pas bientôt fini de s'auto-congratuler benoîtement ?
[^] # 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é à 2.
J'avoue que ça reste encore un peu flou, alors j'essaye de détailler.
Afin de lever toute ambiguïté, je te propose d'utiliser la terminologie suivante (Je sais que vous y réfléchissez encore et j'ai pas mal cogité et bidouillé de mon côté ;-) :
Toute branche au sens de Pijul est appelée ensemble car ce n'est ni plus ni moins que ça - un ensemble de patchs (change) atomiques et de séquences de patch (interdépendants et ordonnés) -.
Par exemple, si on a 2 sous-ensembles dans notre dépôt:
e1={A} et e2={A, D<-E}.
Chacune de ces entités (unités de changement ou séquences) commutent entre elles. On a, de par la commutativité:
{A, D<-E} == {D<-E, A} != {E<-D, A}
(Une séquence ne commute pas entre ses propre constituants mais commute avec les autres entités).
Jusque là, j'ai juste ?
Admettons que l'on incorpore un nouveau change ( pijul pull ) B dans e1 qui entre en conflit et que l'on doive évidemment le résoudre avant de l'intégrer ce qui donne C comme dépendance. ( pijul dependencies)
Si te je suis toujours, on obtient à présent:
e1={A<-C->B}, e2={A, D<-E}
Si j'incorpore les changes de e2 dans e1 ( pijul pull e2), je me retrouve avec
e1={A<-C->B}, e2={A<-C->B, D<-E}
On n'a donc pas eu à ré-effectuer la résolution par nous-même.
C'est bien ça ?
Ce que j'ai du mal à imaginer par contre, c'est un cas où le git rerere ou même le fait de rejouer le même conflit serait nécessaire ici.
Sauf peut-être… si on a commencé à jouer avec des cherry-picks entre 2 branches de release. Et je ne vois pas non plus vraiment, dans quelles situations un rebase (vu en tant que suite de cherry-picks) redemanderait de ré-appliquer les mêmes conflits.
Mais je conviens que l'approche de Pijul est élégante et moins hasardeuse.
[^] # Re: xclass et CDE
Posté par El Titi . En réponse au journal Quel DE pour des débutants?. Évalué à 7. Dernière modification le 13 mai 2019 à 00:34.
Merdouille, il doit y avoir un buffer overflow sur le serveur du site. Tous les screenshots semblent rediriger vers les images d'il y a 15 ans.
Je me charge de signaler ça sur le tracker.
[^] # Re: le web dans sa fange
Posté par El Titi . En réponse au journal Firefox ne peut plus utiliser d'extension. Évalué à 4.
J'adhère totalement à ton discours sur la raison d'être d'une arme à feu (tuer) vs celle du P2P (partager des informations sans centralisation) et dont le piratage n'est qu'un usage détourné
Dommage que tu n'appliques pas le même raisonnement avec la sur la publicité dont l'objet est bien de faire connaître un produit. Dommage que fasses un glissement sémantique. Qu'elle soit "mensongère" n'est aussi qu'un usage détourné. La raison d'être de la pub n'est pas de "mentir" ou d'abuser le consommateur.
(Comme toi j'utilise un filter anti-spam)
[^] # 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ésolé tu as déjà répondu:
https://discourse.pijul.org/t/pijul-0-12-released/313
[^] # 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.
Merci pour cette réponse étayée.
D'un point de vue algorithmique, tout se présente pour le mieux.
Mais malgré tout quelques inquiétudes que je ne semble pas être seul à partager.
Pour accomplir tout ça de manière déterministe, il semble qu'il faille redonder énormément d'informations.
Sur votre discourse, le dernier bench est plutôt encourageant au niveau des perfs:
https://discourse.pijul.org/t/bad-performance/134/11
Sincères félicitations, mais tout de même, 230 Mo de stockage pour 17 Mo de lignes de code ça fait quand même peur.
Je n'ose pas imaginer un dépôt plus conséquent en terme de bande passante au niveau du clone.
Dans ma boîte, on a plusieurs projets de + de 1 Go (avec des binaires, certes) et Bitbucket est carrément à la ramasse avec un clone qui part en timeout.
Mais bon un dépôt de l'ordre de 200 Mo, c'est quand même assez fréquent.
J'espère sincèrement qu'il y a encore matière à optimiser, au moins pour le transport.
En tout cas, c'est déjà un sacré boulot d'accompli.
[^] # 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.
Merci Seb pour ta contribution enthousiaste.
J'ai envie de répondre: Why not ?
Je peux déjà commencer par le dernier point:
Merci aux auteurs de porter le flambeau du Git NG et en guise d'encouragement, je ne peux que citer son papa:
Source
[^] # 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