(et pour relancer un autre troll des cavernes, regardes l'historique de ces derniers jours, c'est assez rigolo)
Il y a plusieurs trucs que je trouve essentiels pour un gestionnaire de version distribué. En fait, le but, c'est qu'il soit utilisable pour une contribution occasionnelle de 50 lignes comme pour du développement au quotidien.
Pour une contribution occasionnelle, ce que tu veux, c'est en une commande, avoire une copie locale et une branche locale, coder, commiter en local, et publier les changements facilement. Par exemple, avec darcs, tu fais "darcs get; ...; darcs record; darcs send" et le patch est envoyé par email au mainteneur. Avec bzr, la version envoie par email n'est pas encore implémentée, mais c'est dans la todolist. Mais "bzr branch" te donne une branche et une copie locale en une commande. Pas la peine de dire ou est le repository, la branche est dans le répertoire .bzr/ de la copie locale.
Pour publier des changements, l'envoie par mail est excellent pour des petites contributions, mais dès que ça prends de l'envergure, il faut pouvoir uploader ça sur un serveur. Et là, l'idée de bzr, héritée de GNU Arch, c'est de n'utiliser qu'un serveur de fichier. Tu as un compte chez free ? bzr push ftp://...@ftpperso/tralala et ta branche est publiée. Ça marche aussi avec sourceforge et gna en sftp par exemple. Le support WebDAV qui permet de passer à travers firewall+proxy pourrait être ajouté assez facilement.
Après, le coup de la branche dans le répertoire de travail, je trouve que ça n'a pas que des avantages. Par exemple, j'ai souvent un répertoire de travail (checkout) sur un disque local non sauvegardé, alors que les données du gestionnaire de version sont bien à l'abris sur un disque réseau sauvegardé périodiquement. Et justement, bzr permet aussi ce mode de fonctionnement. C'est à ma connaissance le seul qui permette de choisir entre "répertoire de travail = repository" et "repository + checkout".
Au niveau performances, il est raisonnablement rapide (derrière mercurial et git pour l'instant), mais il y a encore beaucoup de possibilités d'optimisations, dont certaines prèsque terminées et bientôt intégrées, donc il devrait être encore plus rapide d'ici quelques mois (et pour l'instant, c'est du python pur, sans un gramme d'optimisation en C).
Il y a aussi un système de plugin, que je comparerais aux extensions de firefox : de base, tu as un système simple et relativement minimal, mais tu peux ajouter des trucs plus évolués si ça te chante. Les plugins sont aussi un moyen de tester du code avant de l'intégrer dans bzr lui-même.
[^] # Re: En même temps
Posté par Matthieu Moy (site web personnel) . En réponse au journal Canonical, les « promesses » et la « maintenance » .... Évalué à 5.
(et pour relancer un autre troll des cavernes, regardes l'historique de ces derniers jours, c'est assez rigolo)
Il y a plusieurs trucs que je trouve essentiels pour un gestionnaire de version distribué. En fait, le but, c'est qu'il soit utilisable pour une contribution occasionnelle de 50 lignes comme pour du développement au quotidien.
Pour une contribution occasionnelle, ce que tu veux, c'est en une commande, avoire une copie locale et une branche locale, coder, commiter en local, et publier les changements facilement. Par exemple, avec darcs, tu fais "darcs get; ...; darcs record; darcs send" et le patch est envoyé par email au mainteneur. Avec bzr, la version envoie par email n'est pas encore implémentée, mais c'est dans la todolist. Mais "bzr branch" te donne une branche et une copie locale en une commande. Pas la peine de dire ou est le repository, la branche est dans le répertoire .bzr/ de la copie locale.
Pour publier des changements, l'envoie par mail est excellent pour des petites contributions, mais dès que ça prends de l'envergure, il faut pouvoir uploader ça sur un serveur. Et là, l'idée de bzr, héritée de GNU Arch, c'est de n'utiliser qu'un serveur de fichier. Tu as un compte chez free ? bzr push ftp://...@ftpperso/tralala et ta branche est publiée. Ça marche aussi avec sourceforge et gna en sftp par exemple. Le support WebDAV qui permet de passer à travers firewall+proxy pourrait être ajouté assez facilement.
Après, le coup de la branche dans le répertoire de travail, je trouve que ça n'a pas que des avantages. Par exemple, j'ai souvent un répertoire de travail (checkout) sur un disque local non sauvegardé, alors que les données du gestionnaire de version sont bien à l'abris sur un disque réseau sauvegardé périodiquement. Et justement, bzr permet aussi ce mode de fonctionnement. C'est à ma connaissance le seul qui permette de choisir entre "répertoire de travail = repository" et "repository + checkout".
Au niveau performances, il est raisonnablement rapide (derrière mercurial et git pour l'instant), mais il y a encore beaucoup de possibilités d'optimisations, dont certaines prèsque terminées et bientôt intégrées, donc il devrait être encore plus rapide d'ici quelques mois (et pour l'instant, c'est du python pur, sans un gramme d'optimisation en C).
Il y a aussi un système de plugin, que je comparerais aux extensions de firefox : de base, tu as un système simple et relativement minimal, mais tu peux ajouter des trucs plus évolués si ça te chante. Les plugins sont aussi un moyen de tester du code avant de l'intégrer dans bzr lui-même.