je trouve léger de se repointer avec trois lignes de post et une doc officielle honnêtement indigne
... mais quand même tous les algos qui marchent, pour la première fois !
Tant qu'il y avait des montagnes de bugs que j'étais à peu près le seul à pouvoir attaquer, et qu'on ne savait pas que ça pouvait marcher complètement, la doc n'était pas vraiment une priorité (mais elle est quand même là, le manuel n'est pas indigne).
En plus, comme Pijul est un projet open source, on peut contribuer au manuel si on n'en est pas satisfait ;-)
pourquoi une ligne "ghostée" ne peut pas être "déghostée"? Dire "je remets un truc que j'avais supprimé" a de la valeur pour moi, c'est ce qui m'avais intéressé quand on passait sous git les textes de loi avec le bureau ouvert de l'assemblée nationale.
pijul rollback fait exactement ça, en produisant un patch qui annule les effets d'un autre.
git est orienté état, mais stocke des deltas dans les packfiles. pijul est orienté delta, mais pour la performance vous devez bien stocker des états non?
Il y a deux sujets, l'implémentation et les concepts. En vrai, je pense que tout système de contrôle de versions stocke ou utilise les deux à un moment ou à un autre (y compris Dropbox et Rsync). Même par mail on fait parfois les deux.
Dans Pijul, on stocke des diffs et des états (c'est la principale innovation par rapport à Darcs), mais l'utilisateur n'a absolument jamais besoin d'y penser. Git stocke des diffs et des états (et montre parfois les deux), mais l'objet auquel on doit penser quand on l'utilise est l'état.
vous utilisez les hard links comme le fait git?
Oui, pour "copier" des patchs quand on clone localement. En parlant de ça, je t'encourage aussi à regarder le design de Sanakirja, qui permet de cloner une "base de données" (dictionnaire clef-valeur) sur le disque sans rien copier.
dans les entrailles de git il y a le staging, la base git et le reflog... dans pijul il y a quoi à côte des graggles et de sanakirja? (Dans les entrailles de pijul il y a quoiiii!! sans avoir à lire du rust :D! Le blog de Joe Neeman est pas mal mais largement insuffisant et daté.)
Mais Pijul a un fonctionnement un peu différent de Git, en particulier les structures de données sont plus tordues, et il est donc plus difficile d'y accéder sans... faire un peu de Rust. Ce n'est pas un "mauvais choix de design", c'est un peu une nécessité. Il y a malheureusement un compromis entre la lisibilité des structures de données et la complexité algorithmique des opérations dessus. Ceci dit, on a déjà réfléchi à refactoriser le backend pour le généraliser à des trucs moins efficaces mais plus lisibles (on n'a malheureusement pas de ressources en temps infinies).
Le manuel est aussi open source, il est possible de faire des commentaires (https://nest.pijul.com/pijul_org/manual/discussions/) et de contribuer. On a toujours répondu à toutes les questions qui nous ont été posées sur https://discourse.pijul.org, et presque toujours à celles posées par IRC (irc.freenode.net, #pijul).
votre fonction de hash?
Je suis un peu étonné par cette question, pourquoi c'est important ?
Pour l'instant il n'y en a qu'une implémentée, c'est SHA2-512 (si je me souviens bien), mais on peut la changer très facilement en restant rétro-compatible. On risque de changer la façon de l'utiliser dans les noms de fichiers, parce que les préfixes du base58 (ce qu'on fait aujourd'hui) du hash binaire ne sont pas des base58 des préfixes du hash binaire.
en quoi l'orienté delta de darcs et surtout pijul est une amélioration par rapport aux VCS précédents qui ont eu la même approche (j'avais lu que SVN est orienté delta?)? Bref une histoire en 10 tomes avec delta/état, centralisé/distribué, numéros de versions/hashs... des VCS serait plus que bienvenue.
SVN n'est pas du tout orienté delta, c'est (c'était?) un genre de Git où (commit+push) est une seule opération, que tu ne peux pas séparer. Bien sûr, tous les pushs sont fast-forward (comme dans Git).
L'amélioration numéro 1 c'est d'obéir à une théorie mathématique qui garantit des propriétés intuitives dans 100% des cas. Le seul autre système basé sur des diffs que je connaisse est Darcs (que j'aime beaucoup), et il gère très mal les conflits (mais les détecte très élégamment).
des benchmarks de performance et scaling entre VCS svp!
On n'en est pas encore là, on vient tout juste d'avoir des algos corrects. Avant de pouvoir benchmarker, on doit encore :
Améliorer l'utilisation du disque, et mieux gérer les gros fichiers binaires (pas évident, mais j'ai des idées).
Restreindre pijul record et pijul diff pour qu'ils ne regarde pas les fichiers dont la date n'a pas été modifiée (ça c'est facile)
Encore une fois, on est preneurs de bonnes volontés pour nous aider !
[^] # Re: Gros besoin de vulgarisation dev technique
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 9.
... mais quand même tous les algos qui marchent, pour la première fois !
Tant qu'il y avait des montagnes de bugs que j'étais à peu près le seul à pouvoir attaquer, et qu'on ne savait pas que ça pouvait marcher complètement, la doc n'était pas vraiment une priorité (mais elle est quand même là, le manuel n'est pas indigne).
En plus, comme Pijul est un projet open source, on peut contribuer au manuel si on n'en est pas satisfait ;-)
pijul rollbackfait exactement ça, en produisant un patch qui annule les effets d'un autre.Il y a deux sujets, l'implémentation et les concepts. En vrai, je pense que tout système de contrôle de versions stocke ou utilise les deux à un moment ou à un autre (y compris Dropbox et Rsync). Même par mail on fait parfois les deux.
Dans Pijul, on stocke des diffs et des états (c'est la principale innovation par rapport à Darcs), mais l'utilisateur n'a absolument jamais besoin d'y penser. Git stocke des diffs et des états (et montre parfois les deux), mais l'objet auquel on doit penser quand on l'utilise est l'état.
Oui, pour "copier" des patchs quand on clone localement. En parlant de ça, je t'encourage aussi à regarder le design de Sanakirja, qui permet de cloner une "base de données" (dictionnaire clef-valeur) sur le disque sans rien copier.
J'ai commencé à documenter ça : https://pijul.org/manual/format.html
Mais Pijul a un fonctionnement un peu différent de Git, en particulier les structures de données sont plus tordues, et il est donc plus difficile d'y accéder sans... faire un peu de Rust. Ce n'est pas un "mauvais choix de design", c'est un peu une nécessité. Il y a malheureusement un compromis entre la lisibilité des structures de données et la complexité algorithmique des opérations dessus. Ceci dit, on a déjà réfléchi à refactoriser le backend pour le généraliser à des trucs moins efficaces mais plus lisibles (on n'a malheureusement pas de ressources en temps infinies).
Le manuel est aussi open source, il est possible de faire des commentaires (https://nest.pijul.com/pijul_org/manual/discussions/) et de contribuer. On a toujours répondu à toutes les questions qui nous ont été posées sur https://discourse.pijul.org, et presque toujours à celles posées par IRC (irc.freenode.net, #pijul).
Je suis un peu étonné par cette question, pourquoi c'est important ?
Pour l'instant il n'y en a qu'une implémentée, c'est SHA2-512 (si je me souviens bien), mais on peut la changer très facilement en restant rétro-compatible. On risque de changer la façon de l'utiliser dans les noms de fichiers, parce que les préfixes du base58 (ce qu'on fait aujourd'hui) du hash binaire ne sont pas des base58 des préfixes du hash binaire.
SVN n'est pas du tout orienté delta, c'est (c'était?) un genre de Git où (commit+push) est une seule opération, que tu ne peux pas séparer. Bien sûr, tous les pushs sont fast-forward (comme dans Git).
L'amélioration numéro 1 c'est d'obéir à une théorie mathématique qui garantit des propriétés intuitives dans 100% des cas. Le seul autre système basé sur des diffs que je connaisse est Darcs (que j'aime beaucoup), et il gère très mal les conflits (mais les détecte très élégamment).
On n'en est pas encore là, on vient tout juste d'avoir des algos corrects. Avant de pouvoir benchmarker, on doit encore :
pijul recordetpijul diffpour qu'ils ne regarde pas les fichiers dont la date n'a pas été modifiée (ça c'est facile)Encore une fois, on est preneurs de bonnes volontés pour nous aider !