Le "problème" de bzr, c'est qu'il a essayé d'être bien conçu avant d'essayer d'être fonctionnel. Du coup, forcément, les gens qui ont testé une version 0.0.x ont été un peu décu, mais ça évolue vraiment vite depuis.
Aujourd'hui, je peux faire par exemple:
$ bzr branch http://bazaar-ng.org/bzr/bzr.dev
$ cd bzr.dev
<hack hack hack>
$ bzr commit -m "killer feature"
# Récupérer les modifs de bzr.dev depuis le branch
$ bzr merge
$ bzr commit
# publier mes changements
$ bzr push sftp://shells.sourceforge.net/bla-bla-bla
$ echo "tu peux merger" | mail auteur-de-bzr
Plus tard, il y aura a priori un "brz send" comme le fameux "darcs send".
En ce moment, Canonical est en train de faire sa migration en interne. Pour une idée de la quantité d'archives gérées, voir par exemple http://bazaar.ubuntu.com/ (pour l'instant, ces archives utilisent bazaar 1.x). La notion de gestion de version décentralisée est au coeur de la politique de Canonical et des idées de Mark Shuttleworth : le but est de favoriser la coopération entre les distributions. Quand ubuntu modifie un logiciel pour sa distrib, les modifications sont publiées en utilisant un gestionnaire de versions, c'est à dire proprement, avec un message de commit pour chaque modif, éventuellement plusieurs branches, et pas juste un gros patch. Bref, tout ça pour dire qu'il y a des exigences bien plus importantes que RCS derrière bzr ;-).
Je trouve Bazaar 1 déjà très bon (mais trop compliqué pour les débutants, et pas assez rapide), tu peux te douter que Bazaar 2 a pour ambition d'être mieux.
(ceci dit, le fait que bzr soit bien ne fait pas des autres des mauvais gestionnaires de versions)
[^] # Re: Y'a aussi Bazaar 2
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Conférence Parinux : Les nouveaux systèmes de gestion de version. Évalué à 5.
Aujourd'hui, je peux faire par exemple:
$ bzr branch http://bazaar-ng.org/bzr/bzr.dev
$ cd bzr.dev
<hack hack hack>
$ bzr commit -m "killer feature"
# Récupérer les modifs de bzr.dev depuis le branch
$ bzr merge
$ bzr commit
# publier mes changements
$ bzr push sftp://shells.sourceforge.net/bla-bla-bla
$ echo "tu peux merger" | mail auteur-de-bzr
Plus tard, il y aura a priori un "brz send" comme le fameux "darcs send".
En ce moment, Canonical est en train de faire sa migration en interne. Pour une idée de la quantité d'archives gérées, voir par exemple http://bazaar.ubuntu.com/ (pour l'instant, ces archives utilisent bazaar 1.x). La notion de gestion de version décentralisée est au coeur de la politique de Canonical et des idées de Mark Shuttleworth : le but est de favoriser la coopération entre les distributions. Quand ubuntu modifie un logiciel pour sa distrib, les modifications sont publiées en utilisant un gestionnaire de versions, c'est à dire proprement, avec un message de commit pour chaque modif, éventuellement plusieurs branches, et pas juste un gros patch. Bref, tout ça pour dire qu'il y a des exigences bien plus importantes que RCS derrière bzr ;-).
Je trouve Bazaar 1 déjà très bon (mais trop compliqué pour les débutants, et pas assez rapide), tu peux te douter que Bazaar 2 a pour ambition d'être mieux.
(ceci dit, le fait que bzr soit bien ne fait pas des autres des mauvais gestionnaires de versions)