Certes, mais celui qui l'a rapporté montre aussi qu'un truc qui prend quelques minutes sous Linux (et dont la performance est comparable à la même opération avec Git) n'a toujours pas fini après 1h15 sous ce système. Je ne pense pas qu'il aurait réagi si c'était seulement l'expansion.
Arf, je viens de me rendre compte que mon propos pouvait prêter à confusion : je ne parlais pas de pourrissement par rapport aux usagers qui trollent (tant que le fil de discussion ne s'allonge pas trop) mais par rapport au système qui casse les pieds (on voit avec cet exemple qu'il ne suffit pas de porter pour que ça marche seul, le fait que le comportement de cet exploitant ne soit pas POSIX a toujours des effets de bord curieux.)
L'expansion m'a marqué parce-que plus loin, parlant de *.cpp et non plus *.* comme dans le besoin initial, on voit que le système fait des suppressions wtf
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Puisque tu nous fais l'honneur de faire un petit détour parmi nous,j'aurais une petite question.
Dans la documentation de Pijul (très soignée au demeurant), on lit :
In Pijul, for any two changes A and B, either A and B commute, (in other words, A and B can be applied in any order), or A depends on B, or B depends on A.
J'avoue que je ne saisis pas bien dans quels cas des changes pourraient commuter hormis sur les noms de fichiers d'un répertoire dans lesquels l'ordre n'a effectivement pas d'importance.
La définition de la commutation dans la théorie des patches de Darcs est bien différente et tient compte du contexte. Elle est donc transposable au contenu d'un fichier.
Commuter 2 patches implique d'appliquer une succession de patchs bien différents pour un résultat équivalent.
Elle ne dit pas qu'on peut appliquer A et B dans n'importe quel ordre.
Haha, je suis allé faire un tour sur sa dépêche, après avoir vu sa réponse, et il me semble que c'était expliqué dans les commentaires (mais je ne sais plus si c'était l'un des nombreux fils auxquels tu as participé) : on tient bien compte du contexte… mais surtout tous les patches sont, sauf action explicite, historisés et partagés. Faut que je retrouve les commentaires exactes dans la marée.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par El Titi .
Évalué à 3.
Dernière modification le 21 janvier 2022 à 16:54.
Oui. En m'y repenchant, je pense que c'est un peu expliqué ici. De même, dans le journal était abordé ce concept de "graggle".
Du coup, on s'apeçoit que le contexte et le contenu du change ne désigne pas la même chose, que les définitions et les propriétés ne correspondent pas exactement, donc j'aimerais bien connaître les éléments mathématiques sur lesquels s'appuie l'outil. Non pas que je doute de son bienfondé, mais ça permettrait sans doute de mieux saisir tout le potentiel qui est derrière.
Si les patchs ne sont pas marqués comme dépendants l'un de l'autre (éventuellement avec une chaîne de dépendances entre eux), tu peux vraiment les appliquer dans n'importe quel ordre, et avoir la garantie à 100% d'obtenir le même résultat.
Le cas où Pijul diffère de Darcs est sur les conflits: Darcs définit un conflit en disant que la commutation naïve ne marche pas, alors que Pijul te garantit que tu auras le même conflit indépendamment de l'ordre.
J'ai l'impression que ce projet est en train d'évoluer vers quelquechose de très chouette, peut-être un game-changer, je vous le souhaite. Merci pour ta persévérance au fil des années.
L'UI a bien évolué avec ce concept de channel que je trouve élégant, qui rappelle un peu les streams de Clearcase ou les heads de Hg et qui se matérialisent sous forme de sous-graphes pour illustrer un effort de développement parallèle.
Même si pour Pijul ceci introduit une notion de chronologie qui me parait pas tout à fait rendre justice si l'on considère le commutativité.
La métaphore ensembliste me paraissait plus pertinente. Voire même l'éprouvette dans laquelle on mélange des atomes (patchs independants) et des molécules (patches reliés) alors qu'au final, le mélange donne toujours le même produit. Mais je m'égare.
Etant donné que vous en êtes à la bétâ, et que vous stabilisez, il ne me semple pas avoir vu dans la doc l'équivalent de la commande tag, car après tout, marquer une configuration est quand même le plus important en GCL. A moins que ce ne soit la commande archive.
Je n'ai pas encore expliqué ce que je compte faire avec par contre, mais j'ai l'intention de me servir des tags pour alléger considérablement la taille des dépôts sur le disque, tout en les rendant un poil plus rapide (mais bon, quand on est sur du O(log n), il faut vraiment de grosses réductions de taille pour voir une amélioration en vitesse).
Merci pour le lien. J'ai bien compris que cette opération en elle-même ne constituait pas le plus grand challenge technique et c'est cool que tu envisages de telles optims au passage.
Mais est-ce que ceci signifie que cette commande ne sera pas dispo pour la 1.0 ? (beta = feature freeze)
Par quel moyen, par exemple, pourras-tu identifier cette version, une fois que tu vas la distribuer ?
Est-ce un channel ? Comment le freezer dans ce cas ?
Ça me parait assez primordial, même si ça passe par une implémentation dégradée. En O(n) avec n comme nb de patchs, ça reste satisfaisant.
Posté par pmeunier .
Évalué à 3.
Dernière modification le 23 janvier 2022 à 08:30.
Il y a des tags dans la beta, on peut les utiliser comme des channels en lecture seule. Par contre, la structure de données qui est dessous peut les utiliser pour libérer un peu d'espace disque, mais ne le fait pas encore. Ça ne change rien au format, et l'utilisateur ne voit rien, c'est juste une optimisation rétro-compatible.
Ça me parait assez primordial
Je pense au contraire que c'est un truc pour les très gros dépôts. Même si beaucoup de gens qui veulent tester Pijul le testent sur des dépôts gigantesques, les dépôts gigantesques représentent une infime minorité des dépôts existants.
D'ailleurs, je ne pense pas implémenter ça si (1) je dois le faire tout seul et (2) il n'y a pas de demande industrielle.
Même si pour Pijul ceci introduit une notion de chronologie qui me parait pas tout à fait rendre justice si l'on considère le commutativité.
Il y a plusieurs années, il n'y avait pas de chronologie, ce n'était pas vraiment utilisable, on retrouvait des vieux patchs en tête de log. C'est mieux d'avoir une chronologie souple que pas du tout.
Sur HN, une bonne moitié des discussions tourne autour de Git omniprésent. Ca peut se comprendre puisque les frustrations autour de Git ont motivé Pijul. Cependant :
moi je me demande plutôt comment Pijul se compare/positionne par rapport à Fossil ?
et sinon, en attendant d'être propulsé aussi par un Pijulhub, est-il prévu de faire le pont avec les autres solutions en vogue ? (tout comme le sale gosse a git-svn et que Mercurial avait des tas de passerelles ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
en attendant d'être propulsé aussi par un Pijulhub
Il y a quand même Nest qui fournit (pour le moment) dépôt de code, discussions et "réseau social" (on peut mettre des étoiles !!!). Par contre, pour le moment, c'est pas libre.
Pour l'instant c'est énormément de boulot, et pas (encore) de financement. J'ai un plan pour le financer, dès que ça roule je pense le rendre open source.
Fossil est un genre de Git/Hg/SVN, dans le sens où il a un DAG de snapshots, et les fusionne avec une heuristique. Il n'y a pas vraiment de structures de données intéressante dedans, ni d'innovation par rapport à Git (d'autant qu'il interdit le rebase, et que rebase est quand même un très bon couteau suisse).
Les intérêts de Fossil, du point de vue technique, sont de tout stocker en SQLite. C'est une performance technique qui à mon avis relève plus du défi sportif que d'autre chose, mais pourquoi pas ? Autre intérêt pour certains utilisateurs, il a un gestionnaire de bugs inclus.
Merci pour ce retour. Il avait retenu mon attention justement pour son interface (pas besoin de mettre en œuvre un GitWeb ou Gitea pour le bugs tracker en sus) ainsi que sa clarté (point commun avec Mercurial, tout le contraire de Git dont le modèle de pensée des commandes n'est pas toujours clair et où même des porcelaines sont encore plein de subtilités.) Je déplore presque toujours chaque fois qu'il faut rebaser et sa présence dans Git ne se justifie que par le fait que Git ne fait pas toujours ce qui est attendu si les devs ne se sont pas pliés à lui… Ce sont ces points qui me font penser que c'est un peu le même créneau que Pijul, d'où ma question.
Je n'ai pas regardé ses détails techniques, mais SQLite est utilisé par défaut car charité bien ordonnée… et qu'en fait n'importe quel RDBMS peut être utilisé pourvu que ça parle le SQL standard (si le moteur de bases de données de Pijul répond en SQL rien n'interdit de l'utiliser) J'avais lu que l'auteur préfère utiliser SQL que de devoir réinventer un DSL pour interroger les métas et autres informations. En tout cas, merci encore pour avoir pris le temps de me répondre.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Discussions intéressantes autour de cette annonce (en anglais)
Posté par El Titi . Évalué à 4.
Reddit
Hackernews
[^] # *.cpp et *.*
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
Sur HN la première partie des discussions part sur l'expansion d'un système à jeter par la Fenêtre… Ils ont le chic pour pourrir les débats…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: *.cpp et *.*
Posté par pmeunier . Évalué à 3.
Certes, mais celui qui l'a rapporté montre aussi qu'un truc qui prend quelques minutes sous Linux (et dont la performance est comparable à la même opération avec Git) n'a toujours pas fini après 1h15 sous ce système. Je ne pense pas qu'il aurait réagi si c'était seulement l'expansion.
[^] # Re: *.cpp et *.*
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Arf, je viens de me rendre compte que mon propos pouvait prêter à confusion : je ne parlais pas de pourrissement par rapport aux usagers qui trollent (tant que le fil de discussion ne s'allonge pas trop) mais par rapport au système qui casse les pieds (on voit avec cet exemple qu'il ne suffit pas de porter pour que ça marche seul, le fait que le comportement de cet exploitant ne soit pas POSIX a toujours des effets de bord curieux.)
L'expansion m'a marqué parce-que plus loin, parlant de
*.cppet non plus*.*comme dans le besoin initial, on voit que le système fait des suppressions wtf“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: *.cpp et *.*
Posté par El Titi . Évalué à 2.
Puisque tu nous fais l'honneur de faire un petit détour parmi nous,j'aurais une petite question.
Dans la documentation de Pijul (très soignée au demeurant), on lit :
J'avoue que je ne saisis pas bien dans quels cas des changes pourraient commuter hormis sur les noms de fichiers d'un répertoire dans lesquels l'ordre n'a effectivement pas d'importance.
La définition de la commutation dans la théorie des patches de Darcs est bien différente et tient compte du contexte. Elle est donc transposable au contenu d'un fichier.
Commuter 2 patches implique d'appliquer une succession de patchs bien différents pour un résultat équivalent.
Elle ne dit pas qu'on peut appliquer A et B dans n'importe quel ordre.
[^] # Re: patchs commutatifs
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Haha, je suis allé faire un tour sur sa dépêche, après avoir vu sa réponse, et il me semble que c'était expliqué dans les commentaires (mais je ne sais plus si c'était l'un des nombreux fils auxquels tu as participé) : on tient bien compte du contexte… mais surtout tous les patches sont, sauf action explicite, historisés et partagés. Faut que je retrouve les commentaires exactes dans la marée.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: patchs commutatifs
Posté par El Titi . Évalué à 3. Dernière modification le 21 janvier 2022 à 16:54.
Oui. En m'y repenchant, je pense que c'est un peu expliqué ici. De même, dans le journal était abordé ce concept de "graggle".
Du coup, on s'apeçoit que le contexte et le contenu du change ne désigne pas la même chose, que les définitions et les propriétés ne correspondent pas exactement, donc j'aimerais bien connaître les éléments mathématiques sur lesquels s'appuie l'outil. Non pas que je doute de son bienfondé, mais ça permettrait sans doute de mieux saisir tout le potentiel qui est derrière.
[^] # Re: patchs commutatifs
Posté par pmeunier . Évalué à 5.
La structure qui est derrière est un CRDT un peu particulier, ce qui explique les chouettes propriétés.
[^] # Re: *.cpp et *.*
Posté par pmeunier . Évalué à 6.
Si les patchs ne sont pas marqués comme dépendants l'un de l'autre (éventuellement avec une chaîne de dépendances entre eux), tu peux vraiment les appliquer dans n'importe quel ordre, et avoir la garantie à 100% d'obtenir le même résultat.
Le cas où Pijul diffère de Darcs est sur les conflits: Darcs définit un conflit en disant que la commutation naïve ne marche pas, alors que Pijul te garantit que tu auras le même conflit indépendamment de l'ordre.
[^] # Re: *.cpp et *.*
Posté par El Titi . Évalué à 3.
J'ai l'impression que ce projet est en train d'évoluer vers quelquechose de très chouette, peut-être un game-changer, je vous le souhaite. Merci pour ta persévérance au fil des années.
L'UI a bien évolué avec ce concept de channel que je trouve élégant, qui rappelle un peu les streams de Clearcase ou les heads de Hg et qui se matérialisent sous forme de sous-graphes pour illustrer un effort de développement parallèle.
Même si pour Pijul ceci introduit une notion de chronologie qui me parait pas tout à fait rendre justice si l'on considère le commutativité.
La métaphore ensembliste me paraissait plus pertinente. Voire même l'éprouvette dans laquelle on mélange des atomes (patchs independants) et des molécules (patches reliés) alors qu'au final, le mélange donne toujours le même produit. Mais je m'égare.
Etant donné que vous en êtes à la bétâ, et que vous stabilisez, il ne me semple pas avoir vu dans la doc l'équivalent de la commande tag, car après tout, marquer une configuration est quand même le plus important en GCL. A moins que ce ne soit la commande archive.
[^] # Re: *.cpp et *.*
Posté par pmeunier . Évalué à 4.
La commande tag est évoquée dans le poste de blog, j'ai expliqué comment ça marche là: https://pijul.org/posts/2022-01-07-compressed-sanakirja/
Je n'ai pas encore expliqué ce que je compte faire avec par contre, mais j'ai l'intention de me servir des tags pour alléger considérablement la taille des dépôts sur le disque, tout en les rendant un poil plus rapide (mais bon, quand on est sur du O(log n), il faut vraiment de grosses réductions de taille pour voir une amélioration en vitesse).
[^] # Re: *.cpp et *.*
Posté par El Titi . Évalué à 2.
Merci pour le lien. J'ai bien compris que cette opération en elle-même ne constituait pas le plus grand challenge technique et c'est cool que tu envisages de telles optims au passage.
Mais est-ce que ceci signifie que cette commande ne sera pas dispo pour la 1.0 ? (beta = feature freeze)
Par quel moyen, par exemple, pourras-tu identifier cette version, une fois que tu vas la distribuer ?
Est-ce un channel ? Comment le freezer dans ce cas ?
Ça me parait assez primordial, même si ça passe par une implémentation dégradée. En O(n) avec n comme nb de patchs, ça reste satisfaisant.
[^] # Re: *.cpp et *.*
Posté par pmeunier . Évalué à 3. Dernière modification le 23 janvier 2022 à 08:30.
Il y a des tags dans la beta, on peut les utiliser comme des channels en lecture seule. Par contre, la structure de données qui est dessous peut les utiliser pour libérer un peu d'espace disque, mais ne le fait pas encore. Ça ne change rien au format, et l'utilisateur ne voit rien, c'est juste une optimisation rétro-compatible.
Je pense au contraire que c'est un truc pour les très gros dépôts. Même si beaucoup de gens qui veulent tester Pijul le testent sur des dépôts gigantesques, les dépôts gigantesques représentent une infime minorité des dépôts existants.
D'ailleurs, je ne pense pas implémenter ça si (1) je dois le faire tout seul et (2) il n'y a pas de demande industrielle.
[^] # Re: *.cpp et *.*
Posté par pmeunier . Évalué à 4.
Je réagis aussi sur:
Il y a plusieurs années, il n'y avait pas de chronologie, ce n'était pas vraiment utilisable, on retrouvait des vieux patchs en tête de log. C'est mieux d'avoir une chronologie souple que pas du tout.
[^] # Re: *.cpp et *.*
Posté par El Titi . Évalué à 4.
Absolument! Mais c'est une considération UI.
C'est juste qu'en termes conceptuels, l'analogie avec le labo de chimie me paraît plus pertinente et que la terminologie aurait pu s'en inspirer.
Après c'est du chipotage, je l'admets.
[^] # git-hahaha
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Sur HN, une bonne moitié des discussions tourne autour de Git omniprésent. Ca peut se comprendre puisque les frustrations autour de Git ont motivé Pijul. Cependant :
git-svnet que Mercurial avait des tas de passerelles ?)“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: git-hahaha
Posté par bbo . Évalué à 4.
Il y a quand même Nest qui fournit (pour le moment) dépôt de code, discussions et "réseau social" (on peut mettre des étoiles !!!). Par contre, pour le moment, c'est pas libre.
[^] # Re: git-hahaha
Posté par bbo . Évalué à 4.
Et pour contribuer aux dépôts, il est possible de pousser du code directement dans une discussion. Pas mal.
J'espère que le code de Nest sera rendu public et sous licence libre. Hâte de voir ça.
[^] # Re: git-hahaha
Posté par pmeunier . Évalué à 4.
Pour l'instant c'est énormément de boulot, et pas (encore) de financement. J'ai un plan pour le financer, dès que ça roule je pense le rendre open source.
[^] # Re: git-hahaha
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 22 janvier 2022 à 20:42.
Juste épatant… Si avec ça, ça se fait pas une place de choix je ne sais quoi dire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: git-hahaha
Posté par pmeunier . Évalué à 6.
Fossil est un genre de Git/Hg/SVN, dans le sens où il a un DAG de snapshots, et les fusionne avec une heuristique. Il n'y a pas vraiment de structures de données intéressante dedans, ni d'innovation par rapport à Git (d'autant qu'il interdit le rebase, et que rebase est quand même un très bon couteau suisse).
Les intérêts de Fossil, du point de vue technique, sont de tout stocker en SQLite. C'est une performance technique qui à mon avis relève plus du défi sportif que d'autre chose, mais pourquoi pas ? Autre intérêt pour certains utilisateurs, il a un gestionnaire de bugs inclus.
[^] # Re: git-hahaha
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 22 janvier 2022 à 23:46.
Merci pour ce retour. Il avait retenu mon attention justement pour son interface (pas besoin de mettre en œuvre un GitWeb ou Gitea pour le bugs tracker en sus) ainsi que sa clarté (point commun avec Mercurial, tout le contraire de Git dont le modèle de pensée des commandes n'est pas toujours clair et où même des porcelaines sont encore plein de subtilités.) Je déplore presque toujours chaque fois qu'il faut rebaser et sa présence dans Git ne se justifie que par le fait que Git ne fait pas toujours ce qui est attendu si les devs ne se sont pas pliés à lui… Ce sont ces points qui me font penser que c'est un peu le même créneau que Pijul, d'où ma question.
Je n'ai pas regardé ses détails techniques, mais SQLite est utilisé par défaut car charité bien ordonnée… et qu'en fait n'importe quel RDBMS peut être utilisé pourvu que ça parle le SQL standard (si le moteur de bases de données de Pijul répond en SQL rien n'interdit de l'utiliser) J'avais lu que l'auteur préfère utiliser SQL que de devoir réinventer un DSL pour interroger les métas et autres informations. En tout cas, merci encore pour avoir pris le temps de me répondre.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: git-hahaha
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Il semble aussi, d'après l'historique, qu'il se soit inspiré de Monotone.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.