Il y a un peu plus d'une année, un journal nous présentait Pijul, un nouveau gestionnaire de code source en cours de développement. Il est écrit en Rust. Pierre-Étienne Meunier, un des auteur, a largement commenté le journal.
Une volonté du projet est de fonctionner sur la majorité des plateformes, d'où l'écriture d'une bibliothèque SSH (en Rust également) qui tourne correctement sur Windows. Une plateforme de partage de base de code est disponible : https://nest.pijul.com/
Pijul se base sur une théorie des patches (je recopie ça mais je ne sais pas trop à quoi ça correspond !) mais le journal cité et la documentation apportera des éléments de réponse aux plus curieux.
Le principal apport de cette nouvelle version semble être le clonage partiel avec la commande pijul clone --path ainsi qu'une refonte architecturale pour une amélioration du service rendu.
Vous pouvez suivre l'actualité du projet sur leur blog : https://pijul.org/posts/
# Autres Plateformes
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Et à part nest.pijul.com, y a-t'il d'autres plateformes qui ont adopté Pijul ?
[^] # Re: Autres Plateformes
Posté par Nonolapéro . Évalué à 2.
Sachant que Pijul n'est pas encore totalement prêt, j'ai comme un doute.
[^] # Re: Autres Plateformes
Posté par AncalagonTotof . Évalué à -4.
Je suis rentré dedans carrément dans mon commentaire "On peut troller ou faut attendre vendredi ?", mais je me suis fais descendre à -7 !
Non, franchement, il fallait le prendre au moins au second degré !
Même si on peut aussi le faire au premier …
# Théorie des patches
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Je ne connais pas la théorie des patches, mais je sais que c'est ce qui a été développé pour le gestionnaire de version Darcs.
[^] # Re: Théorie des patches
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Oui c'est en gros la même théorie mais l'objectif est de corriger les défauts de lenteur de Darcs afin de rendre cette théorie utilisable.
[^] # Re: Théorie des patches
Posté par gipoisson . Évalué à 2.
La théorie est utilisable indépendamment de Darcs. Ce dernier est lui aussi utilisable, mais c’est vrai que certaines de ces commandes sont lentes si elles sont appliquées sur un dépôt très vaste, typiquement des dépôts de la grandeur d’un compilateur grand public ou d’un noyau de même nature. Par contre, sur de petits et moyens dépôts, Darcs est tout à fait rapide. Et quelle que soit la taille des dépôts, ses simplicité et élégance à l’usage sont AMHA des atouts à considérer.
Aussi, la compréhension de la théorie des patches n’est-elle pas nécessaire pour se mettre à Darcs. Ceci est un récent fil de discussion (en anglais) qui comporte des éléments de comparaison entre
Git,MercurialetDarcs. Dans la discussion, Ben Franksen est le nom de la personne qui, à mon avis, en connaît le plus sur leDarcsde ces dernières années que n’importe qui d’autre, le mainteneur officiel du projet inclus.# demande d’aide
Posté par abyssy . Évalué à 1.
Bonjour,
Excusez-moi si ce n’est pas tout à fait le bon endroit pour demander de l’aide, mais une âme charitable voudrait-elle bien aider le débutant que je suis :
OS: Ubuntu 18.04.1 LTS x86_64
cargo --versioncargo 1.30.0 (a1a4ad372 2018-11-02)
cargo install pijulerror: failed to run custom build command for
thrussh-libsodium v0.1.3process didn't exit successfully:
/tmp/cargo-installS54SX3/release/build/thrussh-libsodium-034c924411ffd856/build-script-build(exit code: 101)--- stdout
cargo:rerun-if-env-changed=SODIUM_LIB_DIR
cargo:rerun-if-env-changed=SODIUM_STATIC
--- stderr
thread 'main' panicked at 'called
Result::unwrap()on anErrvalue: "\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"did not exit successfully: exit code: 1\n--- stderr\nPackage libsodium was not found in the pkg-config search path.\nPerhaps you should add the directory containinglibsodium.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'libsodium\' found\n"', libcore/result.rs:1009:5RUST_BACKTRACE=1` for a backtrace.note: Run with
warning: build failed, waiting for other jobs to finish…
error: failed to compile
pijul v0.11.0, intermediate artifacts can be found at/tmp/cargo-installS54SX3Caused by:
build failed
À tout hasard je précise que je n’ai eu aucun souci pour installer
ripgrepouraceravec cargo.[^] # Re: demande d’aide
Posté par Bruno Michel (site web personnel) . Évalué à 8.
Essaye de faire un
apt install libsodium-deven root. Je dirais que c'est une bibliothèque en C dont thrussh-libsodium est un wrapper et que cette dépendance de pijul a donc besoin de trouver la bibliothèque en question.[^] # Re: demande d’aide
Posté par abyssy . Évalué à 2.
Bonsoir,
merci beaucoup, cela a résolu le problème.
# On peut troller ou faut attendre vendredi ?
Posté par AncalagonTotof . Évalué à -10.
Le gars qui fait ça, c'est le même que celui qui a pondu systemd ?…
git ?
Ouais, ça marche bien.
On va tout refaire alors !
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 6.
C'est surtout que ton commentaire est véritablement inutile. Tu sors des mots sans que ça n'est le moindre lien avec quoique ce soit. Le fait de dire que tu troll ne suffit pas. Un lancé de troll c'est un art, ça s'apprend et, même pour les meilleurs, des fois ça marche des fois ça marche pas. Mais chouiner quand son troll n'a pas fonctionner ça me paraît être la pire des bassesses.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par AncalagonTotof . Évalué à -10. Dernière modification le 22 novembre 2018 à 12:59.
Est-ce qu'on pourrait tous desserrer les fesses ici ?
Un troll est un art ? Je chouine parce que mon troll n'a pas fonctionné ? C'est une bassesse ? Eh beh !
Et bien non, j'insiste pour les raisons suivantes :
Ça va mieux maintenant ? Tu vois bien le lien entre mes mots et la news cette fois ?
<troll degree="ultimate">ne pas marquer le point godwin, ne pas marquer le point godwin, ne pas ...</troll>
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 5.
Je prends un ton impérieux juste pour le style.
Il ne suffit pas de dire "je troll" pour faire du troll. La définition original du troll c'est de lancer un sujet tumultueux dans une communauté qui n'amène rien (un lancé de trolle plutôt réussi tu as moi pour la version 0.g de weboob). Par extension c'est devenu le nom que l'on donne à celui qui crée un troll.
Depuis l'ère twitter c'est devenu un terme galvaudé (comme "geek" par exemple) où quand on dit plus ou moins n'importe quoi, on affirme qu'« on trolle » et ça passe.
Personnellement je milite pour garder la version originelle de la définition et ne voit pas l'intérêt de la nouvelle sauf dans un effet de mode. Il y a une perte culturelle entre le lancer de troll qui a partir d'un message plutôt anodin génère un flameware et annoncer haut et fort "je troll" pour pouvoir dire "j'y vais fort" ou "je rigole".
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 9.
T'es sérieux ? mercurial fonctionnait bien avant que git arrive. svn avant que mercurial arrive. Le C avant le C++, le C++ avant le rust. Konqueror avant daulphin. bash avant zsh. xterm avant rxvt…
Bref ils expérimentent des approches différentes, tu as mieux à faire ? Cool. Est-ce que leur travaux sont pertinents ? Pour sûr ! Même s'ils n'apportent rien. Le travaille scientifique c'est explorer un certain nombre de piste pour finalement trouver celle qui paraît le mieux. C'est ça la démarche scientifique. La remettre en cause très bien, mais il va te falloir d'autres arguments que « je trolle (hihihi) » si tu ne veux pas être inutile.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par freejeff . Évalué à 3.
Finalement, tu as marché dedans … est-ce qu'il l'a fait volontairement, c'est une autre histoire …
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par raphj . Évalué à 6.
Avant git, svn marchait du tonnerre aussi.
Et avant svn, cvs marchait du tonnerre également.
Et avant systemd, les scripts bash tous dégueulâsses dans tous les sens pour démarrer les services marchaient aussi relativement bien. (voilà, on fait comme ça)
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par RoyalPanda . Évalué à 1. Dernière modification le 22 novembre 2018 à 15:23.
J'avoue que pour le coup celui là fonctionne.
Bref, il y a le bon troller et le mauvais troller…
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par AncalagonTotof . Évalué à -4. Dernière modification le 22 novembre 2018 à 21:14.
OK, barjic, j’admets, j’y suis allé fort. Trop pour toi.
Et t’as réponse de 14h22 est parfaitement fondée : avec mon raisonnement, on en serait encore à voyager à cheval (ça serait peut-être mieux … Ah zut, je peux pas m’en empêcher …).
Non, sans blague, j’admets sérieusement comment tu m’as remis à ma place dans ce post, les arguments sont bons. Si RMS et LT n’avaient pas fait ce qu’ils ont fait (et plein d’autres), on serait tous sous Windows Ou macOS. Ou TOS, je sais pas.
Mais j’ai surtout l’impression que tu ne dois pas rigoler très souvent en prenant tellement au sérieux mon message initial, et en prétextant détenir LA définition du troll.
Moi, j’en ai une beaucoup moins scientifique, et je ne la connais que parce ceux (les trolls) par lesquels je suis passé.
Du coup je suis allé voir ici.
Et franchement, mon post initial était-il réellement si éloigné de :
???
Les mots qui me collent le plus là-dedans sont : distract, digressive, provoking, tangential, amusement.
J’ai pas l’impression de ne pas être troll. J’ai peur que tu campes sur ta propre définition scientifique du troll. J’en déduis qu’on ne poste pas sur le même mode, on ne communique pas dans le même état d’esprit, on n’arrivera pas à se mettre d’accord ici.
Ensuite je reformule et je contre un peu, parce que je ne digère pas tout.
CVS et SVN (me) posaient de sérieux problèmes avant la (ma) bascule vers git.
Petit aperçu : VCS/Features.
Je ne développe pas, surtout parce que j'ai rapidement oublié ce qui marchait mal dans CVS et SVN. Je suis heureux avec Git, et j'ai pas envie de tout changer, tout ré-apprendre.
Et sur quoi je tombe hier soir, en consultant mes sites habituels ?
C'est pas ça qui va me pousser à tout changer, tout ré-apprendre.
Alors oublie ta carrière de scientifique deux secondes, et pense à systemd. Y’a pas comme un air de ressemblance ?
Parce que j’aime bien mes Debian, mais merde, quelle mouche les a piqués quand ils ont décidé d’adopter cette chose qui va à l’encontre de ce qui a fait la réussite des UNIX ?
Ou alors, ils auraient du proposer le choix, avec ou sans systemd. C’est chiant à gérer ? Oui, peut-être. Mais rien que pour le mail, combien de MTA existent ? Tu gardes exim ? Sendmail ? Postfix ? Un autre ? C’est chiant à gérer cette quantité de choix dans les repos, aller, on en garde qu’un seul !
Chercher mieux, oui.
Tout refaire en moins bien, non ! C’est ça que j’ai vu dans Pijul qui passe mal !
Je l’ai pris à la légère, je l’ai exprimé à la légère, et je suis tombé sur un os qui ne m’a toujours pas répondu quand je demande si il desserre les fesses de temps en temps ;-)
(Les smileys sont-ils aussi considérés comme trollesques ? Je demande, hein, je débute apparemment)
Bon, on en reste là ? T'as raison, même si j'ai pas forcément tort ?
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par raphj . Évalué à 2. Dernière modification le 22 novembre 2018 à 21:48.
Et moi, quand je veux faire mes sauvegardes avec rsync, je n'utilise pas SSH, chacun son… ah, merde :-D
Plus sérieusement, git peut aussi cloner à travers ssh, et c'est assez répandu ;-)
Réutiliser ssh dans ces cas permet de ne pas avoir à reconstruire tout un système d'identification et de transport sécurisé. On laisse ça a des gens sont c'est le domaine d'expertise et ça permet de réutiliser les infrastructures déjà en places. Ça me paraît plutôt bien :-)
Postfix, bien sûr. Mais vivement que Lennard nous écrive un bon vieux remplaçant pour retrouver le Simple de SMTP. (ah ah :-D)
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par flan (site web personnel) . Évalué à 2.
Utiliser SSH a quand même des implications au niveau sécurité.
Si tu réutilises le même serveur SSH que pour l'administration distante, tu ouvres l'interface d'administration du serveur au réseau de développement (alors qu'une bonne pratique est d'avoir un réseau d'administration dédié, tous les développeurs n'ont pas à administrer la forge logicielle). De plus, SSH permet de tout faire (c'est même son gros intérêt), s'il y a un souci de restriction sur Gogs/Gitlab/…1, tu as un accès pour exécuter du code distant hyper facilement sur le serveur, voir un accès root gratuit si le souci de config est au niveau de sshd lui-même.
De mémoire, il y avait justement un problème sur une des forges courantes (Gitlab, peut-être ? ) qui permettait d'exécuter du code distant.
ça fonctionne souvent avec un fichier de config SSH pour le compte git, entre autre pour ne pas permettre les commandes shell et identifier l'utilisateur grâce à l'empreinte de sa clef publique. ↩
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . Évalué à 2.
(je suis l'auteur de Thrussh, et un des auteurs de Pijul)
Ça a été ma principale motivation pour écrire Thrussh. Avant, Pijul marchait à travers le client OpenSSH. Et même en temps qu'utilisateur de NixOS et NixOps, je ne sentais pas trop la configuration d'un serveur OpenSSH qui fasse appel à une base de données pour vérifier les clefs des utilisateurs, et serve en même temps pour ouvrir un shell.
Nest.pijul.com a un serveur Thrussh qui écoute les clients demander une ouverture de session, l'exécution d'un programme, mais ne fait rien de tout ça, et se contente de faire croire au client qu'il l'a fait. Quand un client présente une clef, le serveur vérifie qu'elle est dans la base de données. Ensuite, quand il demande une commande shell, le serveur la parse avec une regexp, appelle la fonction correspondante, et renvoie un code d'erreur.
La principale idée est que le code qui a le moins de failles de sécurité est celui qui n'est pas écrit.
Après, quand tu as écrit un serveur, écrire un client n'est pas bien difficile, et ça permet de tester plus en détail. J'ai récemment été assez content de voir que j'avais raison de me méfier des solutions existantes (https://www.cvedetails.com/cve/CVE-2018-10933/). Écrire de l'asynchrone en Rust te force à définir proprement l'automate du protocole, ça évite ce genre de blagues par construction (il y a sans doute plein de trous de sécurité que ça n'évite pas, hein).
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 3.
C'est marrant comme tu prends mon ton au premier degré. C'est le même que je prends à chaque fois qu'il est question de troll. C'est une volonté d'être décalé entre la forme solennelle et le fond qui parle de troll. Je ne sais pas si c'est généralement compris ou pas, mais j'avoue que je m'en fou. Là toi tu te vexe, mais c'est la première fois qu'on me le dit. Je sépare justement mes commentaires avec ton et les commentaires sérieux pour limiter le mélange des genres.
Je ne comprend pas comment tu peux te prévaloir provoquant et te plaindre de te faire inutiler. C'est ce qui me fais réagir généralement: les gens qui se pointent avec leur gros sabots mais qui détalent dès que ça ne se passent pas comme ils le souhaitent. Quand tu trolle préparé toi a perdre du karma, c'est le principe.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par AncalagonTotof . Évalué à -4.
Mon niveau de français a du baisser parce que quand je relis tes commentaires, je ne trouve rien d'autre que du premier degré. Et tu t'étonnes que ça me vexe ? Et tu est certain de ne vexer personne d'autre régulièrement ?
Suis-je le seul ici à n'y voir que du premier degré ? Non, sérieusement, éclairez-moi. Quelle subtilité de la langue me manque-t-il pour saisir un début de second degré ?
Mais vexé n'est peut-être pas le bon terme. Incompréhension. Genre : mais c'est qui ce type qui n'a rien pigé à "ma subtilité" et qui me rentre dedans sans en montrer ?
Nul doute que ce n-ième post sans aucun rapport avec Pijul va se faire inutiler. Mais j'aimerais bien comprendre comment on en est arrivé là, un ptit effort s'il vous plait.
Ah, au fait, pour rester très premier degré, moi aussi je fais du Git via SSH. Tout le temps. J'ai jamais dit que les deux s'excluaient.
Seulement, contrairement à Pijul, les dév de Git ne se sont pas amusé à refaire une lib SSH.
Ou bien j'ai encore raté un second degré ?
Ayatollah du Troll va !
Prenons un autre mot : hacker aussi ça te hérisse le poil ?
Moi aussi, ça me gonfle quand un journaleux mélange hacker et pirate. C'est con, on est obligé de parler de White Hat et Black Hat maintenant. Ou de ré-expliquer tout l'historique si on veut être compris. Voilà, la définition a évolué, contre le bon sens et la logique scientifique. Mais on s'adapte, on fait avec, on reste cool.
Mais j'y pense, tu n'as pas posé ta définition du troll en préambule pour être certain d'être bien compris ?
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par kantien . Évalué à 5.
Non, t'as juste raté la discussion sur le sujet dans le premier journal qui présentait pijul (dont le lien est donné dans celui-ci), discussion qui débute ici.
Tu pourrais aussi lire le reste du fil des commentaires pour avoir une idée de la réponse à la question « pourquoi pijul ? ». ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . Évalué à 3.
Répondre à un troll est-il un art ? On va essayer en tout cas…
Je suis content que tu sois heureux, évidemment. Je ne suis moi-même pas malheureux avec Git, je l'utilise régulièrement pour contribuer à différents projets, avec ou sans GitHub.
Mais comme je l'utilise quand même beaucoup, et que je sais un peu comment il marche, je sais aussi qu'il a de gros problèmes, par exemple quand on essaie de l'utiliser soit un peu trop vite (en essayant d'être un peu trop "agile", à l'approche d'une deadline par exemple), soit avec un peu trop d'utilisateurs. Ces problèmes, ainsi que les problèmes d'UI sont théoriques
Le premier problème de Git est le manque de commutation des changements :
git log -paffiche un patch (des changements), pas un commit (une version) !Le deuxième problème de Git est l'absence d'associativité des changements. Si je
git commitA, puis que jegit pullB et C en même temps, ça ne fait pas toujours la même chose que si je commit A, puis que jegit pullB, puisgit pullC. Ça, c'est parce que l'algo de merge de Git est un algo d'optimisation que a parfois plusieurs solutions, auquel cas il en choisit une arbitrairement (sans même en avertir l'utilisateur). Et ça arrive même en l'absence de conflits.Pourquoi Git fait ça comme ça ? La réponse est purement technique, c'est parce que gérer des patchs, ça rend les changements asynchrones, et qu'on ne comprend pas grand chose à l'asynchronisme, en pratique comme en théorie. C'est pour ça que Git séquentialise tout. C'est ça qui le rend monstrueusement rapide et relativement économe en espace disque (ça, et 10 ans de développement d'une grosse communauté).
Mais Git contraint les projets un peu trop gros ou un peu trop agiles à une organisation très rigoureuse, qui n'a pas souvent grand chose à voir avec les contraintes du projet. Je travaille régulièrement sur des projets suffisament contraints par ailleurs (des articles de recherche ou du code scientifique) pour ne pas vouloir me rajouter des bâtons dans les roues exprès.
Tout ré-apprendre, non! Apprendre RCS, CVS, SVN, Git prend du temps et ne finit jamais vraiment, parce qu'il n'y a pas d'algorithme propre derrière, ces outils marchent la plupart du temps, mais (1) ne modélisent pas très bien le problème de travail collaboratif, et (2) sont contraints, pour une raison ou pour une autre, à utiliser des heuristiques au lieu d'algos bien définis.
C'est un peu la même situation que les langages système avant C et Unix : tout le monde faisait une tambouille qui ne marchait pas trop mal, mais il a suffi d'un design rationnel comme C (même s'il n'est pas parfait) pour qu'on n'entende plus trop parler des BASIC, FORTRAN et autres COBOL (bien sûr, ces langages existent encore, mais ils ont été marginalisés et/ou forcés d'adopter des features de C, comme malloc et free pour FORTRAN, par exemple).
Pour la même raison, on peut imaginer que personne ne "fera jamais le tour" de C et C++. En tant que programmeur (et chercheur en info), j'aime bien voir une machine basée sur une théorie rationnelle travailler pour moi. C'est peut-être une satisfaction marxiste, et très clairement une satisfaction moderniste, mais c'est une satisfaction quand même.
Si une machine peut vérifier mon code pour moi, pourquoi vouloir à tout prix le faire à la main ? Le code que j'écris en Rust n'est pas très différent de ce que j'écrirais en C++, mais il est entièrement vérifiable par un algo basé sur une théorie cohérente. En utilisant ce genre de langage, je passe mon temps à écrire du code presque correct, et à laisser le compilateur me guider pour finir de l'écrire correctement.
En C, je passerais mon temps à débugger des erreurs d'allocation mémoire ou de concurrence, et je continuerais à les faire jusqu'à la fin des temps, parce que je suis un être humain. En Rust, je fais ces erreurs aussi, mais plutôt que de passer une semaine à les corriger, le compilateur Rust me les signale en quelques millisecondes.
Ça c'est facile. Ce ne sont bien sûr pas mes oignons, mais à l'avenir, pour des trolls de meilleure qualité, je te conseille de te documenter un peu mieux.
La motivation de la lib SSH, c'est simplement parce qu'il n'existait pas de bibliothèque SSH en C pour écrire un serveur, qui soit documentée correctement. Et la seule bibliothèque utilisable pour écrire un serveur (libssh) est bourrée de failles un peu triviales, est très mal documentée, et son code est assez horrible.
Écrire ça en Rust permet d'écrire (pour la première fois) un serveur avec quasiment les perf de C++, avec un automate de protocole clairement défini qui évite plein de failles classiques (je n'ai aucun mérite, ça marche juste parce qu'une machine le vérifie), avec une API super modulaire et facile à utiliser.
Qui a dit que Pijul remplace SSH ? Comme quoi parfois il vaut mieux chercher un peu à savoir…
J'espère ne pas avoir sorti trop de choses de leur contexte. Je choisis de ne pas répondre au "point systemd", sorte de point Godwin du geek Debian. Tu es vraiment un Hitler du contrôle de version !
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 2. Dernière modification le 05 décembre 2018 à 18:50.
Merci pour ton commentaire :)
Hum… Non ? git t'oblige à avoir une copie de travail (clone), ensuite le fait de faire une branche c'est juste une bonne pratique. D'ailleurs c'est une vue de l'esprit, ce que tu fais c'est donner un nom à ta partie de travaille.
C'est pas une contrainte folle.
Tu peux très bien te retrouver avec un historique non linéaire en git, mais tu va te faire mal. C'est pas de la faute de git. Comprendre un historique non linéaire est une plaie. Trouver une erreur dans une jungle de patch est à des magnitudes plus compliquées qu'avec un log linéaire. Merger plus de 2 fichiers est aussi bien plus compliqué, déjà qu'en merger 2 est casse gueule.
C'est vraiment décidable d'avoir A(B(C())) == A(C(B())) ?
Et qu'avoir un historique compréhensible c'est sacrément pratique pour maintenir ton logiciel ou pour l'auditer. Surtout que je ne vois pas la contrainte que cela pose. Éventuellement tu peux me parler du fait que ça contraint celui qui veux fusionner son code à faire en sorte qu'il fusionne correctement.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par seveso . Évalué à 1.
Entièrement d'accord. Sauf que je ne vois pas en quoi git garantit un historique compréhensible. Bien au contraire.
Ayant utilisé SVN par le passé y a un truc qui m'a vite choqué avec git c'est de parcourir séquentiellement un historique avec des identifiants de révisions imbitables et des dates de commit dans le désordre. Je trouve ça moins beaucoup moins lisible qu'un historique SVN avec des identifiants de révision incrémentés et dont les dates sont dans l'ordre chronologique.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 3. Dernière modification le 06 décembre 2018 à 00:20.
Git ne te garanti rien du tout. Je suis qu'avoir un historique linéaire est plus compréhensible qu'un historique "asynchrone".
Pour tes remarques, je ne vois pas l'intérêt d'un tris par date. C'est l'ordre d'application qui est intéressant (à partir du moment où on veut un historique linéaire). Les identifiants incrémentaux de commit posent de gros problèmes, quand on réécrit l'historique, un identifiant change de commit. Il n'identifie pas un commit, il représente un index. Ça peut très bien s'ajouter dans un git log et tu peux nativement identifier tes commits par des index decrementaux. C'est pas un véritable problème au final.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par seveso . Évalué à 1.
C'est exactement ça qui rend si souvent l'historique d'un projet git difficilement lisible, c'est qu'on peut "réécrire l'historique". Dans SVN on ne peut pas changer le passé (sauf si on est admin du dépôt).
En tout cas j'ai pas l'intention de faire une quelconque comparaison entre SVN et git, je vois assez bien les avantages/inconvénients de chacun. Je voulais juste signaler qu'un historique compréhensible avec git ça nécessite des efforts de la part des humains et que ça n'a absolument rien de systématique.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par seveso . Évalué à 1.
trop tard pour éditer mon précédent commentaire alors je complète ici
En fait j'ai encore du mal à voir à quoi ça pourrait ressembler un historique asynchrone. Intuitivement j'aurais même tendance à ranger git dans cette catégorie "historique asynchrone" et à ranger SVN dans la catégorie "historique linéaire".
Si quelqu'un de pédagogue pouvait éclairer ma lanterne.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . Évalué à 2.
Oublions pour un moment les problèmes d'UI (Git n'a pas besoin de serveur, SVN oui, et c'était casse-pieds. Git est vraiment mieux là-dessus, et d'ailleurs des non-techniciens peuvent l'utiliser même sans comprendre grand chose).
D'un point de vue théorique, Git et SVN sont tous les deux assez synchrones, dans le sens où ils forcent un ordre entre les opérations. On peut faire plus synchrone : Google Docs, par exemple, ou d'autres CRDTs. Git peut sembler un peu plus asynchrone que SVN, parce qu'il n'ordonne pas des opérations qui touchent à des branches différentes. Mais comme dans ce cas les opérations touchent nécessairement à des morceaux différents du dépôt, on ne peut pas vraiment parler d'asynchronisme.
Pijul, par contre, est complètement asynchrone : les contraintes d'ordre entre deux opérations sont réduites au strict minimum (essentiellement, on ne peut pas renommer un fichier, ou écrire dedans, avant d'avoir créé ce fichier). Dans Pijul, en dehors de cette contrainte, l'ordre n'a pas d'importance, puisque tous les ordres possibles aboutiraient au même résultat (les entrailles de Pijul sont mathématiquement un peu subtiles pour garantir ça, mais ça marche).
Mais comme les auteurs de Pijul font quand même du logiciel (y compris Pijul lui-même), ils comprennent quand même la contrainte des historiques clairs. Et dans Pijul, chaque branche se rappelle de l'ordre dans lequel les patchs ont été appliqués. Mais ça n'a pas d'importance, et d'ailleurs on peut enlever un patch en plein milieu (si les dépendances sont respectées) sans affecter le reste.
Avant Pijul, il y avait Darcs et Camp. Plus d'infos sur la clarté de l'historique là : https://www.youtube.com/watch?v=iOGmwA5yBn0
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par pmeunier . Évalué à 2. Dernière modification le 06 décembre 2018 à 10:29.
Est-ce que l'objectif est de défendre Git coûte que coûte, ou de comprendre mes arguments ? Dans le doute, je vais faire comme si c'était de comprendre mon argument.
C'est un peu plus qu'une bonne pratique, c'est la seule solution pour faire commuter des patchs indépendants, et le seul avantage de Git sur SVN (un gros avantage, on est d'accord). La commutation du travail est la principale intuition derrière le contrôle de versions distribué, c'est le truc que les algos de merge de Git essaient de simuler.
100% d'accord, mais je maintiens que ce n'est pas pour une bonne raison, c'est juste parce que Git ne me laisse pas parler de patchs sans avoir à rebaser (un peu comme à l'époque où SVN ne me laissait pas parler de commit sans avoir à merger).
Je suis partiellement d'accord, et c'est d'ailleurs pour ça que Pijul a les deux. Dans Pijul, une branche a un historique linéaire et un ensemble de patchs.
Ça permet d'enlever des patchs presque n'importe où dans l'historique sans avoir à rebaser. Et deux historiques qui contiennent les mêmes patchs, même pas forcément dans le même ordre, produisent toujours les mêmes fichiers (ce n'est pas toujours le cas dans Git, même quand les commits ont été mis dans le même ordre à coups de rebase).
Pour trouver une erreur, j'imagine que tu fais référence à
git bisect. C'est carrémment possible dans Pijul, même si on ne l'a pas encore implémenté, et on peut même isoler des ensembles de patchs bien plus finement que dans Git.C'est vrai quand on merge avec une "heuristique qui marche souvent". Quand on a un algo de merge qui vérifie certains axiomes pratiques, et où tout est réversible, c'est plus facile. Bien entendu, travailler ensemble et se mettre d'accord c'est dur dans la vraie vie, donc fusionner des changements l'est aussi. Mais au moins, Pijul ne le rend pas plus dur que la vraie vie en introduisant des sources d'erreurs techniques.
Dans Pijul la commutation BC=CB est décidable, parce que des patchs qui ne commutent pas se référencent toujours explicitement (ou via une chaîne de dépendances), donc des patchs créés indépendamment commutent toujours (donc c'est décidable). À ce sujet, dans Darcs, la commutation est décidable sans conflits, et avec des conflits non-triviaux je ne comprends pas trop ce qu'il fait.
Mais là, c'est plutôt A(BC) == (AB)C. Et c'est décidable si A, B et C sont des patchs produits par Pijul, puisque c'est toujours le cas (une machine de Turing qui voudrait le décider s'arrêterait tout de suite sans regarder les patchs, et répondrait "oui").
Et d'ailleurs, Pijul peut même améliorer la qualité de l'historique par rapport à Git ! Vu que Pijul n'a pas besoin de rebaser des changements pour les appliquer sur une autre branche, on peut retracer l'historique des changements, qui serait complètement perdus sinon. C'est bien pratique quand on a une branche instable et une branche stable, par exemple, et qu'on fait passer les correctifs de bugs de la branche instable à la branche stable.
Ça, en Git, ce serait un cauchemar, géré à coups de rebases et autres "rerere", au prix de longues et stressantes heures de travail qui auraient peut-être été mieux investies à réfléchir à l'algo ou à écrire du code.
Clairement, quand on travaille tout seul sur une histoire linéaire, ou qu'on s'organise suffisamment bien pour découper le projet à l'avance sans jamais changer radicalement d'organisation, Git ne pose aucune contrainte.
Mais dès qu'on bosse sur un projet un peu moins bien défini, ou qu'on veut revenir en arrière de façon un peu non-triviale (annuler le patch d'avant-hier, mais pas celui d'hier), ou fusionner des branches temporairement, ou "cueillir des cerises", ça devient super contraint.
Attention, je n'ai pas dit impossible, Git permet bien de faire tout ce qu'on veut. J'ai juste dit "contraint", ce qui implique que ça engendre des coûts de maintenance importants dans certains projets.
[^] # Re: On peut troller ou faut attendre vendredi ?
Posté par barmic . Évalué à 3.
Sacré procès d'intention. Je suis pas fan de git, je préfère hg et surtout je trouve que l'hégémonie de git est un vrai problème (il rend l'arrivé de nouveaux comme pijul ou fossil par exemple).
Je ne sais pas ce que tu entends par « commuter ».
Qu'est-ce que tu entends par historique ? De ce que je comprends il n'y a pas de relation d'ordre entre les patchs pijul, donc je vois pas ce qui est linéaire.
Oui et non, je n'ai pas donné le nom d'un outil parce que c'est pas simplement ça. Juste si tu veut comprendre l'historique pouvoir dans ta tête le suivre linéairement aide beaucoup.
Je n'ai pas la sensation que git augmente cette difficulté, mais j'avoue n'avoir rien qui me permettent de l'affirmer.
Je pense que j'ai du mal avec ça. Il faudrait que je touche un peu avec pour que ça fasse réellement sens pour moi. Je comprends ce que tu veux dire, mais je vois pas comment ça fonctionne.
J'essaierais de prendre le temps de jouer avec parce qu'il y a trop de choses qui restent abstraites pour moi.
# Théorie des patchs ?
Posté par pmeunier . Évalué à 1.
Pas besoin de savoir ce que veut dire "théorie des patchs" pour l'utiliser. En vrai, c'est une structure de données qui garantit que les patchs se comportent bien, c'est-à-dire qu'ils vérifient certains axiomes :
Mais le pari de Pijul, c'est qu'en vrai, on n'a pas besoin de savoir ça. La théorie des patchs en pratique, ça veut juste dire que tout se passe conformément à l'intuition. Dans Pijul, les branches ne servent qu'à suivre plusieurs versions du projet en parallèle (branche stable et instable, par exemple, mais pas besoin de branches pour contribuer à un projet).
[^] # Re: Théorie des patchs ?
Posté par barmic . Évalué à 2.
Du coup ça se passe comment ? Je clone le dépôt. Je fais un truc, mon patch est matérialisé comment ? Il est relié à quoi ?
[^] # Re: Théorie des patchs ?
Posté par pmeunier . Évalué à 1.
Il y a une structure de données interne qui modélise ton dépôt. Ton patch est créé, appliqué à cette structure de données, enregistré dans un fichier, et ajouté à l'historique de la branche.
Je ne suis pas sûr de savoir à quoi il est "relié", mais je pense que tu veux parler de ce que Pijul appelle des "dépendances", qui sont d'autres patchs. Si on voulait simuler Git avec Pijul, il suffirait que chaque nouveau patch ait le dernier patch comme unique dépendance (ce qui impliquerait qu'il a aussi tous les autres, par transitivité).
(si j'ai mal compris la question n'hésite pas à la reposer)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.