(Pour info, y'a un peu de code à moi dans tla, et j'étais un des contributeurs principaux de Xtla, une interface pour tla dans Emacs, donc tout ça me rappelle de vieux souvenirs...)
Avec tla, tu traquais toutes les branches distantes à la manière de git avec ses références.
Pas vraiment : avec tla, le stockage était distribué au sens où chacun avait son bout de branche sur son serveur, mais ce bout de branche ne contenait que les patchs de la branche en question. C'était hyper fragile : si l'archive distante disparaissait, tout ce qui était construit dessus devenait plus ou moins inutilisable. Baz avait commencé à ajouter une notion de cache local pour éviter de refaire des accès distants à chaque fois qu'on accédait à un commit. Le principe d'avoir en local toutes les révisions et de pouvoir les identifier avec une référence n'existait pas dans tla.
Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer foo--bar--1.0, les convention de nommages de ++fichiers,,inhabituelles, ...) que Linus n'aurait jamais imaginé ajouter dans Git à mon avis (ou en tous cas, j'espère ;-) ).
À l'inverse, un peu après que Linus a démarré Git, Tom Lord avait commencé un concurrent qu'il appelait revc et qui était en gros « tla next generation, basé sur les concepts de Git », sauf que ça n'a jamais pris.
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.
Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks. La différence, c'est que dans Mercurial, chaque commit contient le nom de la branche correspondante, alors que les branches Git et les bookmarks font l'inverse : c'est la branche qui sait quels commits elle contient, et les commits n'ont pas l'info.
[^] # Re: Intuitif
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
(Pour info, y'a un peu de code à moi dans tla, et j'étais un des contributeurs principaux de Xtla, une interface pour tla dans Emacs, donc tout ça me rappelle de vieux souvenirs...)
Pas vraiment : avec tla, le stockage était distribué au sens où chacun avait son bout de branche sur son serveur, mais ce bout de branche ne contenait que les patchs de la branche en question. C'était hyper fragile : si l'archive distante disparaissait, tout ce qui était construit dessus devenait plus ou moins inutilisable. Baz avait commencé à ajouter une notion de cache local pour éviter de refaire des accès distants à chaque fois qu'on accédait à un commit. Le principe d'avoir en local toutes les révisions et de pouvoir les identifier avec une référence n'existait pas dans tla.
Et il y avait tout un tas de bizarreries dans tla (genre les branches qu'il fallait absolument nommer
foo--bar--1.0, les convention de nommages de++fichiers,,inhabituelles, ...) que Linus n'aurait jamais imaginé ajouter dans Git à mon avis (ou en tous cas, j'espère ;-) ).À l'inverse, un peu après que Linus a démarré Git, Tom Lord avait commencé un concurrent qu'il appelait revc et qui était en gros « tla next generation, basé sur les concepts de Git », sauf que ça n'a jamais pris.
Mercurial savait faire des branches nommées dans un seul dépôt bien avant l'arrivée des bookmarks. La différence, c'est que dans Mercurial, chaque commit contient le nom de la branche correspondante, alors que les branches Git et les bookmarks font l'inverse : c'est la branche qui sait quels commits elle contient, et les commits n'ont pas l'info.