Le but est (était ?) de comparer les gros trolls velus que certaines grandes gueules bien connues peuvent pondre parfois.
Je n'ai en aucun cas prétendu que Linus avait raison, et d'ailleurs, comme je l'avais dit quand j'avais traduit son troll lors de la sortie de la dernière version de Linux, sur ce point précis il avait tort. (Mais son opinion sur Subversion demeure.)
Sur ce point précis :
Un utilisateur est venu demander si on pouvait modifier Git pour disposer d'un numéro de révision qui s'incrémente monotoniquement, pour pouvoir faire comme sur les projets qui utilisent Subversion, et dire simplement aux utilisateurs "utilise la révision 393" ou "c'est corrigé dans la révision 532".
Linus est parti de travers la dessus (ce qui lui arrive rarement), et a donc pondu ces phrases mémorables sur la qualité de CVS et Subversion (bon ça, ça lui arrive plus souvent), et notamment une grande tirade sur la numérotation des branches dans CVS (1.1.1.5, ce genre de trucs effectivement bien horrible mais qui n'avait rien à voir avec ce que l'utilisateur demandait).
Après un petit recadrage d'autres contributeurs de Git, les arguments suivants ont été retenus :
- C'est faisable dans Git, mais ça fait une métadonnée à mémoriser en plus, et un changement qui impacte pas mal de commandes de Git
- Communiquer une version abrégée de l'identifiant du commit concerné fonctionne aussi bien ("utilise le commit 5ef24" ou "c'est corrigé dans le commit 63b43")
- Ce genre de communication est plus liée à un projet organisé autour d'un référentiel centralisé et qui utilise peu de branches ; dans les projets plus distribués et/ou qui utilisent plus de branches, on a plutôt tendance à dire "utilise la branche new_features" ou "c'est corrigé dans la branche bugfixes".
Au final, vu tout ça, la conclusion a été "si quelqu'un le veut vraiment, qu'il propose un patch".
Sur Subversion et CVS :
C'est tout l'argument centralisé contre distribué, politique des projets, etc. qu'il faudrait reprendre. Ce que je ne vais pas faire là maintenant.
[^] # Re: Monotone
Posté par Boa Treize (site web personnel) . En réponse à la dépêche bzr 0.11 vient de sortir. Évalué à 6.
Je n'ai en aucun cas prétendu que Linus avait raison, et d'ailleurs, comme je l'avais dit quand j'avais traduit son troll lors de la sortie de la dernière version de Linux, sur ce point précis il avait tort. (Mais son opinion sur Subversion demeure.)
Sur ce point précis :
Un utilisateur est venu demander si on pouvait modifier Git pour disposer d'un numéro de révision qui s'incrémente monotoniquement, pour pouvoir faire comme sur les projets qui utilisent Subversion, et dire simplement aux utilisateurs "utilise la révision 393" ou "c'est corrigé dans la révision 532".
Linus est parti de travers la dessus (ce qui lui arrive rarement), et a donc pondu ces phrases mémorables sur la qualité de CVS et Subversion (bon ça, ça lui arrive plus souvent), et notamment une grande tirade sur la numérotation des branches dans CVS (1.1.1.5, ce genre de trucs effectivement bien horrible mais qui n'avait rien à voir avec ce que l'utilisateur demandait).
Après un petit recadrage d'autres contributeurs de Git, les arguments suivants ont été retenus :
- C'est faisable dans Git, mais ça fait une métadonnée à mémoriser en plus, et un changement qui impacte pas mal de commandes de Git
- Communiquer une version abrégée de l'identifiant du commit concerné fonctionne aussi bien ("utilise le commit 5ef24" ou "c'est corrigé dans le commit 63b43")
- Ce genre de communication est plus liée à un projet organisé autour d'un référentiel centralisé et qui utilise peu de branches ; dans les projets plus distribués et/ou qui utilisent plus de branches, on a plutôt tendance à dire "utilise la branche new_features" ou "c'est corrigé dans la branche bugfixes".
Au final, vu tout ça, la conclusion a été "si quelqu'un le veut vraiment, qu'il propose un patch".
Sur Subversion et CVS :
C'est tout l'argument centralisé contre distribué, politique des projets, etc. qu'il faudrait reprendre. Ce que je ne vais pas faire là maintenant.