Même mercurial qui tenait bien la route s'est fait enterrer par Git...
Mercurial n'apporte pas grand chose par rapport à Git, c'est essentiellement les mêmes algos, avec les mêmes merges, la même gestion des conflits. L'interface est un peu plus facile, mais moins rapide.
Au fait, il y a un GSoC Mercurial cette année pour tenter adopter l'algo de Pijul pour leurs merges.
Cela veut dire qu'on peut réécrire l'ordre de l'historique d'un projet ? Et si c'est le cas, n'est-ce pas une anti-feature ?
Ce n'est pas une anti-feature, pour trois raisons :
D'abord parce qu'on peut rester "en mode Git" (en faisant des tags au lieu des records), c'est-à-dire que si l'ordre est vraiment important, on peut le maintenir si on veut. Dans ce cas, on ne profite pas à 100% de la commutation, dans le sens où on ne va plus pouvoir éditer les vieux patchs indépendamment des nouveaux. Par contre, dans ce cas, on a quand même des merges déterministes, et une algèbre claire et bien définie (ce qui n'est pas du tout le cas dans Git). Les conflits sont aussi gérés proprement (contrairement à Git, qui ne les représente simplement pas en interne).
Ensuite parce que dès qu'on travaille à plusieurs, ou même sur plusieurs choses en même temps, le travail sur un projet n'est pas une suite linéaire de patchs. C'est Git qui a tort sur ce point, la "vraie" histoire est presque toujours plus compliquée.
Dans Pijul, chaque dépôt a sa propre histoire, et Pijul la connaît (pijul log sait l'afficher, par exemple). Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.
[^] # Re: Difference Pijul vs Git
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 10.
Mercurial n'apporte pas grand chose par rapport à Git, c'est essentiellement les mêmes algos, avec les mêmes merges, la même gestion des conflits. L'interface est un peu plus facile, mais moins rapide.
Au fait, il y a un GSoC Mercurial cette année pour tenter adopter l'algo de Pijul pour leurs merges.
Ce n'est pas une anti-feature, pour trois raisons :
D'abord parce qu'on peut rester "en mode Git" (en faisant des tags au lieu des records), c'est-à-dire que si l'ordre est vraiment important, on peut le maintenir si on veut. Dans ce cas, on ne profite pas à 100% de la commutation, dans le sens où on ne va plus pouvoir éditer les vieux patchs indépendamment des nouveaux. Par contre, dans ce cas, on a quand même des merges déterministes, et une algèbre claire et bien définie (ce qui n'est pas du tout le cas dans Git). Les conflits sont aussi gérés proprement (contrairement à Git, qui ne les représente simplement pas en interne).
Ensuite parce que dès qu'on travaille à plusieurs, ou même sur plusieurs choses en même temps, le travail sur un projet n'est pas une suite linéaire de patchs. C'est Git qui a tort sur ce point, la "vraie" histoire est presque toujours plus compliquée.
Dans Pijul, chaque dépôt a sa propre histoire, et Pijul la connaît (
pijul logsait l'afficher, par exemple). Mais comme deux ensembles de patchs identiques produisent toujours le même résultat, même dans des ordres différents, l'ordre a largement moins d'importance que dans Git.