http://bazaar.canonical.com/BzrFAQ(...) 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.
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.
bazaar sait utiliser les archives tla. Si tu as une archive tla, tu n'as rien a faire pour utiliser bazaar.
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.
> On peut aussi générer des checkpoints tous les N révisions
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.
GNU Arch 2.0 est fortement inspiré de git. Je ne crois pas que le format de stockage soit le même par contre.
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, ...
> Tla (et baz) n'ont pas de rapport avec bazaar-ng.
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.
Pour le format de stockage de bazaar-ng, c'est en principe temporaire. Normalement, l'API interne pour accéder aux fichiers d'une révision donnée est suffisament bien faite pour qu'un changement du format d'archive ne casse pas le reste du code. Il faut garder en tête que bazaar-ng n'est qu'un projet très jeune et encore en développement, mais AMA très prometteur.
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.
> Pour ma part, je pense que Tom Lord a été un frein pour le projet.
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é:
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 !
La GPL est un contrat entre deux parties. L'auteur accèpte de te distribuer quelque chose, en échange, l'utilisateur s'engage à accepter certaines conditions.
Si "l'utilisateur", c'est une boite qui a décidé de violer la GPL, et de redistribuer le même soft sous une autre licence, alors, il ne tient pas ses engagements, donc l'auteur peut effectivement s'estimer laisé. Je ne dit pas qu'il obtiendra forcément les sources, mais il peut demander des domages et intérêts.
Si tu violes la license d'un logiciel MS, et qu'il y a une plainte, crois-tu que le tribunal va juste te dire : « Bon, allez, vous avez utilisé illégalement le logiciel XYZ pendant 10 ans. Maintenant, ça suffit, en punition, rendez-moi ce CD piraté, rentrez chez-vous et on n'en parle plus. ».
Le mec qui a ton mot de passe utilisateur, il installe un graber de clavier sur ton compte, et il attends. Le mot de passe root finit toujours par tomber.
Je serais bien surpris que tu n'ai pas quelqu'un dans ton entourage qui ai à la fois l'ADSL et un graveur de CD. Fait-toi graver les 3 premiers par exemple (je ne retrouve plus la liste des packages par CD), et tu seras tranquile.
Pour vraiment bien faire, il faudrait gérer aussi le multi-utilisateur, parce que quand j'ai un fichier à copier pas urgent et qu'un autre utilisateur est en train de faire une copie (depuis un TX de la salle d'à coté), ça pourrait être intéressant d'attendre qu'il ai fini. Il faudrait aussi gérér la proximité sur le disque, parce que si j'ai deux fichiers A et B dans la file, qu'ils sont fragmentés, et qu'il y a des bouts de A à coté des bouts de B, ça peut être intéressant de les prendre au passage.
C'est fou ce que ça commence à ressembler à un bout du kernel, tout ça.
(par ailleurs, le scheduler d'IO de Linux n'est peut être pas parfait, mais c'est là qu'il faut travailler si on veut améliorer les accès concurrent, pas trop dans le gestionnaire de fichier).
> ça prendra globalement le même temps si il ne fait rien à côté,
Ça, ça dépends de ta config. Sur une machine avec plusieurs disques et/ou des disques réseau, ça n'est plus vrai du tout.
Et puis, si j'ai une grosse copie de fichier en tâche de fond, que je copie un petit fichier en même temps, j'ai pas envie qu'il me dise "Attends, je finie de recopier Debian-dvd.iso et je m'occupe de ton toto.txt juste après".
Bref, y'a des cas ou ça serait pas mal, mais il y a AMA plus de cas ou ça serait génant.
Tu as quand même pleins de cas ou tu as le choix dans l'implémentation d'une structure de donnée entre optimiser en mémoire ou optimiser en temps.
Il y a 15 ans, en général, il valait mieux optimiser en mémoire, mais aujourd'hui, il vaut mieux optimiser en temps.
Typiquement, pleins de programmes actuels gardent un cache en mémoire du résultat de certaines opérations pour éviter d'avoir à les refaire. Ca bouffe de la mémoire, mais c'est une optimisation quand même.
Tout ceci étant dit, il y a quand même beaucoup de gaspillage de RAM aujourd'hui et c'est dommage.
Je comprends pas trop l'intérêt. Justement, ton OS gère très bien les accès concurrent (on n'est plus sous DOS ;-) ), donc pourquoi ne pas le laisser faire ?
Pour contribuer à de l'existant, la majorité des programmes GNOME sont en C à ma connaissance. Un nouveau dans une équipe de dev qui inclue du code Java et C++ dans un projet en C, ça peut être une bonne source de troll, mais ça n'ira pas très loin ;-).
Si tu as distribué le programme sous GPL, alors, tu t'es toi même engagé à filler les sources, t'es mal.
Sinon, on peut dire après coup : « Ah, bah, t'avais pas le droit de faire ça ». L'auteur du code GPL peut s'estimer laisé et demander le reste du code sous GPL en dédomagement, mais ce n'est pas dit qu'il l'obtienne.
[^] # Re: 42 !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La réponse est 42. Évalué à 2.
[^] # Re: Quelqu'un a la bande annonce ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La réponse est 42. Évalué à 4.
Une bonne raison pour ne pas installer mozilla-mplayer ?
Sinon, en général, on s'en sort avec "view page source" et wget.
[^] # Re: Enemy Territory fully GPL ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le moteur du jeu Quake 3 en GPL. Évalué à 5.
# Tant qu'on parle de GNU Arch ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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.
[^] # Re: l'UI ? quelle UI ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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 Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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: Précisions ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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: C'est rassurant
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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: mercurial
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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 Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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 Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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 Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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.
# Précisions ...
Posté par Matthieu Moy (site web personnel) . En réponse au journal Tom Lord abandonne GNU Arch. É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: Compatibilité BSD ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 2.
Si "l'utilisateur", c'est une boite qui a décidé de violer la GPL, et de redistribuer le même soft sous une autre licence, alors, il ne tient pas ses engagements, donc l'auteur peut effectivement s'estimer laisé. Je ne dit pas qu'il obtiendra forcément les sources, mais il peut demander des domages et intérêts.
Si tu violes la license d'un logiciel MS, et qu'il y a une plainte, crois-tu que le tribunal va juste te dire : « Bon, allez, vous avez utilisé illégalement le logiciel XYZ pendant 10 ans. Maintenant, ça suffit, en punition, rendez-moi ce CD piraté, rentrez chez-vous et on n'en parle plus. ».
[^] # Re: Linspire
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une étude pour utiliser Linspire dans les collèges de l'Indiana. Évalué à 3.
[^] # Re: Linspire
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Une étude pour utiliser Linspire dans les collèges de l'Indiana. Évalué à 2.
Le mec qui a ton mot de passe utilisateur, il installe un graber de clavier sur ton compte, et il attends. Le mot de passe root finit toujours par tomber.
[^] # Re: Plus simple ?
Posté par Matthieu Moy (site web personnel) . En réponse au message Installer un environnement graphique sans le réseau. Évalué à 2.
[^] # Re: Ca économise 200 euros
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche 64000 packs de CD de Logiciels Libres distribués aux lycéens auvergnats. Évalué à 2.
# Plus simple ?
Posté par Matthieu Moy (site web personnel) . En réponse au message Installer un environnement graphique sans le réseau. Évalué à 4.
[^] # Re: navigateur de fichier et gestion de l'ordonnancement des tranferts.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 3.
C'est fou ce que ça commence à ressembler à un bout du kernel, tout ça.
(par ailleurs, le scheduler d'IO de Linux n'est peut être pas parfait, mais c'est là qu'il faut travailler si on veut améliorer les accès concurrent, pas trop dans le gestionnaire de fichier).
[^] # Re: navigateur de fichier et gestion de l'ordonnancement des tranferts.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 4.
Ça, ça dépends de ta config. Sur une machine avec plusieurs disques et/ou des disques réseau, ça n'est plus vrai du tout.
Et puis, si j'ai une grosse copie de fichier en tâche de fond, que je copie un petit fichier en même temps, j'ai pas envie qu'il me dise "Attends, je finie de recopier Debian-dvd.iso et je m'occupe de ton toto.txt juste après".
Bref, y'a des cas ou ça serait pas mal, mais il y a AMA plus de cas ou ça serait génant.
[^] # Re: Au lieu de te prendre la tête
Posté par Matthieu Moy (site web personnel) . En réponse au journal La mémoire ne se trouve pas dans les poubelles ... où rarement. Évalué à 3.
Il y a 15 ans, en général, il valait mieux optimiser en mémoire, mais aujourd'hui, il vaut mieux optimiser en temps.
Typiquement, pleins de programmes actuels gardent un cache en mémoire du résultat de certaines opérations pour éviter d'avoir à les refaire. Ca bouffe de la mémoire, mais c'est une optimisation quand même.
Tout ceci étant dit, il y a quand même beaucoup de gaspillage de RAM aujourd'hui et c'est dommage.
[^] # Re: navigateur de fichier et gestion de l'ordonnancement des tranferts.
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 2.
[^] # Re: Pour faire simple...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Aperçu en français de GNOME 2.12. Évalué à 3.
Pour contribuer à de l'existant, la majorité des programmes GNOME sont en C à ma connaissance. Un nouveau dans une équipe de dev qui inclue du code Java et C++ dans un projet en C, ça peut être une bonne source de troll, mais ça n'ira pas très loin ;-).
[^] # Re: Compatibilité BSD ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche La GPL version 3 pourrait sortir en 2007. Évalué à 3.
Si tu as distribué le programme sous GPL, alors, tu t'es toi même engagé à filler les sources, t'es mal.
Sinon, on peut dire après coup : « Ah, bah, t'avais pas le droit de faire ça ». L'auteur du code GPL peut s'estimer laisé et demander le reste du code sous GPL en dédomagement, mais ce n'est pas dit qu'il l'obtienne.