El Titi a écrit 3948 commentaires

Je pense que les 2 produits (Tuleap et Gitlab) ne se positionnent pas exactement sur le même périmètre, même s'il y a d'importants recoupements de fonctionnalités en tant que forges logicielles.

La cible de Tuleap est clairement la pile Atlassian complète pour permettre ce qu'on appelle pompeusement la "Gestion du Cycle de Vie" (ALM=Application Lifecycle Management) dont voici quelques fonctionnalités:
* Le contrôle de source et la revue de code
* L'intégration continue
* Le suivi des demandes de changements
* La gestion de projets
* La gestion des tests
* La gestion documentaire
* La gestion de portefeuilles de projet
…

Je vais te donner quelques références du monde Atlassian pour servir de base de comparaison:
* Le contrôle de source = Bitbucket
* L'intégration continue = Bamboo ou n'importe quel outil de CI (Jenkins,
* Le suivi des demandes de changements = JIRA + integration avec Bamboo et Bitbucket
* La gestion de projets = JIRA (et JIRA Agile pour Scrum et Kanban)
* La gestion des tests = plugins dans JIRA par exemple Xray ou Zephyr
* La gestion documentaire = Confluence(wiki)
* La gestion de portefeuilles de projet = JIRA Portfolio
Et il y a pléthore d'extensions possibles (Help Desk, Q&A à la Stack Overflow, …)

Gitlab ne couvre que:
* Le contrôle de source et la revue de code
* L'intégration continue = Gitlab CI (uniquement mais très bien intégré)
* Le suivi des demandes de changements
* Gestion de projet (relativement limitée mais suffisante pour de petits projets agiles)
* La gestion documentaire =wiki

J'ignore si tous ces éléments sont en opensource et il faut bien avoir conscience que certaines fonctionnalités cruciales pour une entreprise (integration avec des annuaires par ex) sont payantes. Ce qui est normal puisque c'est leur business model.

Pour Tuleap:
* Le contrôle de source et la revue de code (compatibilité Subversion)
* L'intégration continue (connecteur Jenkins)
* Le suivi des demandes de changements
* Gestion de projet (relativement limitée mais suffisante pour de petits projets agiles)
* La gestion documentaire (wiki)
* La gestion des tests = incluse mais payante.

A toi donc de faire ta liste de spec pour mieux cibler la solution que tu recherches mais aussi distinguer ce qui est en opensource (ou gratuit) ou non dans leurs offres.

Sinon, si tu recherches juste une extension open source qui ne couvre que la gestion de projet et qui s'adosse à une forge hébergée (Github, …), tu peux aussi jeter un coup d'oeil à https://taiga.io/.
Il est vraiment très simple d'approche (voir simpliste) mais quand même à peine plus structuré qu'un Trello de base sans plugin.

Je ressens la même chose, n'étant pas un "lecteur rapide".

Afin de d'officialiser cet ostracisme flagrant, je propose de renommer sur ce site la lecture inclusive en:

lecture in.ex.clusive

j'avoue avoir vot*er* négatif.

Heu… non rien

C'est chouette les nuances. L'air de rien, tu nous balances que "l'aversion" contre les LGBTs, ce n'est pas comparable à "l'homophobie".

J'attends ta définition exacte: comme tu sembles très au fait des échelles de valeurs et ne confonds homosexualité, pédérastie et pédophilie, par exemple.

Peux-tu indiquer quels messages tu estimes être homophobes et qui sont pertinentés ?
Au hasard: https://linuxfr.org/users/maderios--2/journaux/agressions-insultes-harcelement-cinq-mois-de-violences-contre-les-lgbt-en-france#comment-1771429

Tu m'objecteras que le score est à -10, mais on constate quand même qu'un tel message avec des relents de "chemises brunes" (https://fr.wikipedia.org/wiki/Triangle_rose) emporte 1/3 d'adhésion (le score des partis d'extrême droite ou de droite "décomplexée", étonnamment)

Tu interprèteras ça à ta manière (dissonance cognitive à l'appui), personnellement je concède une certaine facho-"phobie" dans le sens littéral du terme.

Mais OUAIIIIS !

En fait, t'es un génie. Cette pratique que tu évoques a un nom: la pédérastie, qui entretient cet amalgame avec l'homosexualité, la pédophilie… et les 2 initiales que je ne citerai pas pour ne pas me faire censurer.

And so ? les LGBTs, ont-ils le droit d'être considéré(e)s comme des citoyen(ne)s à part entière ? De ne pas subir de discriminations ?
Ou ils doivent se planquer et renier leur déviance "consciente" (comme l'explicitent les dégénérés corticaux qui relèguent "Idiocracy" à un reportage de Paris Match) ?
Je suis tout ouïe.

Au fait, on progresse dans les milieux non "dichotomiques" au sujet de la dénonciation des actes pédophiles ?
https://www.mediapart.fr/journal/france/200317/des-dizaines-de-pretres-exfiltres-travers-le-monde

El Titi (Gay Friendly)

C'est être d'une mauvaise foi e

Ah ça, la cirrhose est clairement une cause "nationale"

ils sont incapableS de s'inscrire dans une nation ou un peuple,

Ah oui c'est vrai que tu es un vrai patriote. Tu aimes ton pays, comment pouvons-nous en douter ?

https://www.youtube.com/watch?v=GkprBmXED4o

he mais non je n'ai pas peur, si si vous êtes phobe

C'est une manière policée de ne pas froisser les bien-pensant de ton "espèce". Mais si tu préfères "hater" ou hypocrite, on s'en accommodera.

Moi par exemple, je ne suis pas cathophobe. Je suis "anti"clérical. Tu saisis la nuance.

….mais il ne faudrait donc pas le dire** par risque de "communautarisme"** ?
… ils arrivent désormais chez nous.
C'est un cancer social je le redis. La marque d'une décadence civilisationnelle alors qu'on veut vous vendre ça pour du "progrès". Sous couvert de plus de libertés individuelles, ils veulent plus que "les autres" qui sont les autres ? De la division, toujours plus de dichotomie, il veulent qu'on les reconnaissent pour leur … car c'est ce qui les définit, sous couvert d'agression par des "majorités". Il veulent des majorités oppressantes et des minorités oppressées, ils sont incapable de s'inscrire dans une nation ou un peuple, ils veulent la dichotomie …. C'est d'un risible absolu, alors que sur le papier ils sont déjà égaux, devant la fiscalité, la loi, la justice, les impôts, le code de la route.
Tout cela n'aura aucune fin et toujours plus de revendications. …

J'ai laissé quelques trous dans le message de notre interlocuteur. Je vous laisse en exercice d'y placer les minorités qui vous dérangent et de ne pas oublier de bien voter comme par exemple

https://www.cnre.eu/la-ligne-claire

https://youtu.be/pG5C8DIIu6g

J'entends déjà l'harmonieux claquement des bottes !

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.

Il se rapproche quand même plus de Mercurial qui l'a inspiré.

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.

Tu bloubes :D

https://linuxfr.org/users/benoit_in/journaux/pijul-un-nouveau-gestionnaire-de-source#comment-1714073

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.

Il y avait Bitkeeper aussi.
En plus c'est un open source. A merde, ça s'est venu 10 ans après !

Ok je crois que je je commence à piger.

Au départ on a

A:
toto.txt
a

B:
toto.txt
b

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)

ours:

toto.txt
a
b

theirs:

toto.txt
tadaa

Je vais tester tout ça.
Merci

Je m'excuse mais tu m'as perdu.

Pour rappel sur ton exemple:

(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.

C'est pas bientôt fini de s'auto-congratuler benoîtement ?

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.

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.

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)

Désolé tu as déjà répondu:

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.

https://discourse.pijul.org/t/pijul-0-12-released/313

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.

Merci Seb pour ta contribution enthousiaste.

J'ai envie de répondre: Why not ?

Je peux déjà commencer par le dernier point:

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.

No false modesty ;)

Source