Tom Lord, mainteneur de GNU Arch, un programme de gestion de sources, a décidé d'abandonner le poste de mainteneur de GNU Arch.
Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.
Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)
Le post sur la mailing list:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)
Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)
Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.
Enfin, bonne chance à Tom Lord pour ces futurs projets.
# mercurial
Posté par Antoine . Évalué à 4.
J'ai ensuite découvert Mercurial, un autre système de gestion de versions distribué qui bénéficie d'un format de stockage et de transmission réseau beaucoup plus efficace. A titre d'exemple, trois mois d'historique de la branche de Linus du noyau 2.6 ne prennent que 200 Mo (pour environ 5000 changesets), et quelques minutes à télécharger avec un ADSL 1024.
Mercurial est très intéressant car, comme Bazaar-ng, il est écrit en Python, il dispose d'à peu près les mêmes fonctions, et il est beaucoup plus performant.
La page d'accueil de Mercurial :
http://www.selenic.com/mercurial/(...)
Comparaison Mercurial / git / BitKeeper :
http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)
Naviguer dans le miroir sous Mercurial de Linux 2.6 (branche Linus) :
http://www.kernel.org/hg/linux-2.6/(...)
Cloner cette branche dans un repository local :
$ hg clone http://www.kernel.org/hg/linux-2.6/(...) hg-linux
[^] # Re: mercurial
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
http://linuxfr.org/~GomGom/18736.html(...)
http://linuxfr.org/~GomGom/18881.html(...)
[^] # Re: mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ceci dit, il y a pas mal de gens aussi qui considèrent que le format d'archive avec toutes les révisions d'un fichier stockées intégralement est une bonne chose. C'est ce que fait git, et ce que fait GNU Arch 2.0 (qui a mon avis n'a aucun avenir, mais bon ...). Quand l'archive est locale (c'est souvent le cas pour de la gestion de version distribuée), accéder à la revision n d'un fichier est quasi immédiat.
Moi, j'aime bien le système de bazaar (et de tla) avec une archive "delta-compressée", qui contient le strict minimum, et une "revision library", sorte de cache local, qui contient toutes les revisions. Du coup, je sais ou sont les données importantes qu'il faut répliquer et sauvegarder régulièrement, et c'est très économe en bande passante.
[^] # Re: mercurial
Posté par Sebastien . Évalué à 1.
Ca me fait penser que j'ai vu ici[1] un debut de rumeur disant qu'il serait possible que Arch utilise le format de stockage de git.
D'ailleurs il semblerait que certaines personnes (autres que les gens de LKLM) soient interesses par la possibilite d'avoir git comme remplacant a CVS/SVN[1] (et demandent notamment a SourceForge de proposer cette alternative)...
[1] http://kerneltrap.org/node/5557(...)
[^] # Re: mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
De toutes façons, GNU Arch 2.0 était développé uniquement par Tom, il a fait ça dans son coin, et vraissemblablement, il l'abandonne. Ça n'a pas l'air d'avoir beaucoup d'avenir, ...
[^] # Re: mercurial
Posté par Antoine . Évalué à 2.
On peut aussi générer des checkpoints tous les N révisions histoire de borner le nombre d'opérations nécessaire pour récupérer une révision arbitraire.
Encore un autre système très simple : stocker les révisions en entier, mais les concaténer par blocs de N et gzipper la concaténation. C'est simple et très efficace, puisque ça exploite naturellement la très grande redondance entre révisions. C'est ce que j'ai fait dans le petit système de versions codé pour SPIP (j'y divise en plus le texte en courts fragments et ce sont les fragments auxquels j'applique cette technique, ce qui diminue la distance entre les parties redondantes).
[^] # Re: mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ce que font tla et bazaar par exemple (cached revision).
Encore mieux, on peut ajouter des "ponts" entre les revisions. Par exemple, une révision stockée en "full" toutes les 100 révisions, le diff par rapport à la version n-10 toutes les 10 révisions, en plus des diffs pour chaques révisions.
Ca faisait d'ailleurs partie des multiples projets jamais réalisés de Tom pour tla.
En fait, c'est à peu près ce que fait un bon système de backup : Un backup full de temps en temps, un incrémental de niveau 1 régulièrement, et un backup incrémental de niveau 2 tous les jours, par exemple.
[^] # Re: mercurial
Posté par HappyPeng . Évalué à 3.
Aujourd'hui personne n'utilise encore bazaar-ng (pas plus que tla 2.0) et ce n'est pas un projet fini.
J'ai également du mal à voir en quoi le fait que bazaar-ng et mercurial soient écrits en python constitue un avantage.
[^] # Re: mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Faut le dire vite.
L'histoire commence le jour ou les gens de canonical se disent que tla est bien, mais que "it sucks"(tm). Ils décident de créer bazaar, qui est un projet à court terme, pour faire quelque chose qui "sucks less". bazaar-ng (bazaar, next generation), financé par la même boite, est un projet à plus long terme pour faire quelque chose qui "does not suck at all" (désolé pour l'anglais, mais j'avais trouvé les expressions assez représentatives -- dans un post d'Aaron Bentley si mes souvenirs sont bons).
bazaar-ng est fortement inspiré de bazaar, et de son coté, bazaar intègre petit à petit les concepts de bazaar-ng (et se caractérise lui-même comme "seamless upgrade path to [WWW] bazaar-ng"). A terme, les formats d'archives seront compatibles.
[^] # Re: mercurial
Posté par Antoine . Évalué à 0.
Certes mais il est probable que bazaar-ng est amené à remplacer baz/tla. Et il est soutenu par Canonical, ce qui lui donne un certain potentiel.
J'ai également du mal à voir en quoi le fait que bazaar-ng et mercurial soient écrits en python constitue un avantage.
1) Ca évite des tas des bugs potentiels "bas niveau" liés à C/C+, et permet de se concentrer sur l'amélioration des algos. (par rapport à git, Subversion & co)
2) C'est un langage connu et simple d'abord (contrairement à Haskell, le langage de darcs, par exemple)
Bref, Python facilite la contribution et l'amélioration du projet.
[^] # Re: mercurial
Posté par HappyPeng . Évalué à 2.
Le fait qu'un projet soit codé dans un langage "simple d'abord" n'est pas une avancée en soit, car il est tout de même assez rare que les gens qui apprennent un langage, python, parce qu'il est simple d'abord écrivent le code aussi bien que ceux qui ont l'habitude du C, par exemple.
Enfin, Tom Lord a réussi à écrire ce qui est pour moi le meilleur SCM du moment sans être financé ni soutenu par une grande équipe de développement (qu'il l'ait refusée ou non), donc le soutien par Canonical, ça m'est quand même relativement égal.
[^] # Re: mercurial
Posté par Antoine . Évalué à 2.
Non mais des tas de gens apprennent Python alors qu'ils savent *dejà* programmer correctement (y compris en C, assembleur...) et ils se sentent beaucoup plus productifs une fois débarrassés des tâches routinières que l'on passe son temps à refaire en C.
(la même remarque serait valable à peu de choses près pour Ruby et d'autres langages du même niveau)
# Précisions ...
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
s/Pour ma part, je pense que //
> L'objectif de bazaar était de refondre l'UI
s/L'objectif/Le pretexte/
;-).
En fait, Canonical était dans une situation un peu délicate : Le but final était de faire évoluer GNU Arch, sachant que Tom refusait la plupart des patchs. Ils voulaient AMA éviter un fork agressif, et ont donc appelé ça une "branche" à la place d'un fork. N'empêche qu'un des premiers changements introduits par bazaar, c'est un changement du format d'archive, qui n'est pas franchement une question d'interface utilisateur.
Pour ce qui est d'éviter le fork agressif, c'est raté:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1502(...)
Bon, en tous cas, si il y avait encore des utilisateurs de tla, maintenant, vous n'avez plus d'excuses pour ne pas tester bazaar, c'est vraiment bien. Encore pleins de bonnes choses en préparation pour la future 1.5 !
[^] # Re: Précisions ...
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
J'avais pas osé.
[^] # Re: Précisions ...
Posté par Vincent Bernat (site web personnel) . Évalué à 1.
Il y a un truc que je n'ai toujours pas compris : est-ce qu'il faut convertir les archives ? Il me semble que non, mais je n'ai rien trouvé sur le wiki l'indiquant clairement. Est-ce que le fait d'utiliser bazaar empêche les autres d'utiliser tla ?
[^] # Re: Précisions ...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
bazaar sait créer des archives au format tla, c'est une option de make-archive.
tla sait aussi utiliser et créer des archives au format bazaar depuis la version 1.3.2 ou quelque chose comme ça. Tom ne pensait pas en faire le format d'archive par défaut, mais il s'est gouré en appliquant le patch, et c'est donc le format par défaut maintenant.
Bref, le changement de format d'archive n'est doublement pas un problème.
[^] # Re: Précisions ...
Posté par Antoine . Évalué à 3.
Mouarf. Il a l'air en effet assez spécial, ce Tom Lord :))
[^] # Re: Précisions ...
Posté par Ramso . Évalué à 3.
# C'est rassurant
Posté par salvaire . Évalué à 2.
[^] # Re: C'est rassurant
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Tom avait peur qu'ajouter gettext à tla en fasse un bloatware ;-).
http://lists.gnu.org/archive/html/gnu-arch-users/2004-06/msg00143.h(...)
Mais bazaar est internationalisé (pas entièrement traduit, mais l'infrastructure est en place en tous cas).
[^] # Re: C'est rassurant
Posté par Ramso . Évalué à 2.
# l'UI ? quelle UI ?
Posté par Epsos . Évalué à 1.
J'ai essayé octopus qui est très bien, mais sauf si j'ai loupé quelque chose, ça ne permet que de visualiser les patchset. Il y a un autre projet en GTK (archway ?) que j'avais essayé, mais j'avais trouvé qu'au niveau ergonomie c'était pas vraiment ça...
Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs qui marcherait au dessus d'un back end (cvs, subersion, tla, git, ...)
L'idée serait de faire l'interface d'un rcs ultime avec des capabilities (est-ce que tu supportes telle opération) et ensuite de montrer une vue du projet en utilisant l'implémentation du vrai rcs.
A+
David
[^] # Re: l'UI ? quelle UI ?
Posté par Edouard Gomez (site web personnel) . Évalué à 1.
L'UI ligne de commande de arch/tla.
[^] # Re: l'UI ? quelle UI ?
Posté par Epsos . Évalué à 0.
[^] # Re: l'UI ? quelle UI ?
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
C'est pas parce que c'est en ligne de commande que c'est pas destiné aux utilisateurs. Une interface graphique, c'est une GUI.
[^] # Re: l'UI ? quelle UI ?
Posté par Epsos . Évalué à 1.
[^] # Re: l'UI ? quelle UI ?
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
< pub >
Si tu n'es pas alergique à Emacs, il y a Xtla ( http://wiki.gnuarch.org/xtla(...) ).
< /pub >
Sinon, en mode texte, bazaar 1.5 aura une option --modifying FILE pour tracker l'historique d'un fichier, et fai permet de faire pas mal de choses aussi.
> Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs
Dans Emacs, il y a un truc qui ressemble à ça: VC. Mais ça ne permet pas grand chose.
[^] # Re: l'UI ? quelle UI ?
Posté par Epsos . Évalué à 1.
J'ai jamais pu me faire à emacs, c'est certainement bien dommage, et oui, je savais que tu t'occupais de xtla (j'avais lu l'annonce ici meme de la 1.0 et j'avais retenu ton pseudo) :-)
J'aime beaucoup WinCVS pour sa vue à plat, ses filtres, sa possibilité de faire un graphe des révisions pour un fichier et de voir ses diffs. Il y a un outil web (proprio malheureusement) qui permet meme de reconstuire la liste des patchset et d'avoir une vue un peu plus moderne. Je pense donc sérieusement qu'on peut faire quelque chose de sympa.
Les commandes de base seraient :
- checkout (tla get)
- lister les changements (tla changes)
- faire un diff par rapport à n'importe quel autre révision (tla file-diff étendu ?) au sein d'une branche ou de plusieurs branches
- lister toutes les révisions d'un fichier (??)
- comitter un fichier ou un ensemble de fichiers (tla commit --)
- avoir une vue par patch (ce que fait octopy)
- avoir des commandes pour faire des move et des delete
- avoir une commande pour faire un undo/redo (tla undo, tla redo, simulable en cvs)
- ...
Bref, cette interface "ultime" peut être assez simple au départ, mais permettre dans un premier temps d'avoir une vue d'un projet cvs/subversion/tla sympa avec des vues synthétiques pertinentes.
Les opérations en ecriture pourraient être envisagées dans un deuxième temps.
# Tant qu'on parle de GNU Arch ...
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
As of August 2005 Canonical has decided to focus our ongoing efforts on the Python Bazaar-NG codebase. We're switching our efforts, and our internal projects, onto Bazaar-NG in late 2005. For the moment Bazaar is still the more mature and stable codebase, but that's changing.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.