Planet Ubuntu-fr - Bazaar
lundi, janvier 21 2008
Une approche communautaire des supports de formation commerciaux via Bernard.opic
Traduction française de l’article “A community approach to commercial training materials“.
Auteur : Mark Shuttleworth - Traducteur : Bernard Opic
—
Est-il possible d’avoir des supports de formation développés en partenariat avec la communauté, disponibles sous licence CC, ET accessibles via des centres de formation ? C’est ce que nous essayons de voir chez Canonical avec notre cours [...]
jeudi, janvier 10 2008
Bonne conception architecturale en couches et Bzr 1.1 via Bernard.opic
Traduction française de l’article “Good architectural layering, and Bzr 1.1“.
Auteur : Mark Shuttleworth - Traducteur : Bernard Opic
—
J’ai complètement oublié de parler de la version 1.0 de Bzr l’année dernière, mais c’était une excellente mouture et au dire de tous, très bien reçue. Félicitations à la communauté Bazaar pour leur dynamisme ! Je crois que [...]
vendredi, novembre 23 2007
Est-ce possible d'utiliser le launchpad pour un projet professionnel non open-source ? via Administrateur
J'utilise au quotidien l'excellent gestionnaire de versions (VCS) nommé Bazaar.
Cette application est omniprésente dans le monde ubuntero car c'est le VCS supporté par défaut par Launchpad, la méga plateforme permettant de gérer la communauté, les bugs, les spécifications, les traductions d'Ubuntu.
Launchpad est une EXCELLENTE plateforme pour gérer tout ça.
Ce soir à l'une des réunions de Giroll, j'ai demandé à Nicolas Derive - un des rares Ubuntu Members français, et accessoirement Girollien - quelles étaient les limites de l'hébergement de projet sur le Launchpad.
Sur la page de création d'un nouveau projet (il faut peut-être identifié pour la voir, je ne l'assure pas), il est précisé :
Donc d'après le titre, il faut que ce soit un projet open source. Mais plus bas, après de nombreux détails, on peut voir, dans le choix des licences disponibles :
Ainsi on a le droit de choisir entre autres une licence propriétaire ?
Nicolas me signale aussi que l'on peut restreindre l'accès à un dépôts bazaar aux personnes d'une team, de même pour les rapports de bugs.
Donc la question que je me pose : j'ai un projet professionnel développé en PHP5, pas spécialement propriétaire mais en tout cas pas open source non plus (quand même un projet commercial à la base). Je me sers de Bazaar pour gérer les versions car j'apprécie la possibilité de commiter en étant hors-ligne.
Puis-je légalement utiliser le Launchpad pour un projet pro non open source, restreindre l'accès aux sources et aux bugs à une team qui ne comporte que moi et éventuellement deux ou trois contacts ?
Je ne compte pas le faire, mais c'est une question que je me pose. Dans la logique je trouverais étrange que ce soit possible mais au fond pourquoi pas ?
Vous avez une réponse et/ou une opinion, ça m'intéresse ?
Est-ce possible d'utiliser le launchpad pour un projet professionnel non open-source ? via BastNic
J'utilise au quotidien l'excellent gestionnaire de versions (VCS) nommé Bazaar.
Cette application est omniprésente dans le monde ubuntero car c'est le VCS supporté par défaut par Launchpad, la méga plateforme permettant de gérer la communauté, les bugs, les spécifications, les traductions d'Ubuntu.
Launchpad est une EXCELLENTE plateforme pour gérer tout ça.
Ce soir à l'une des réunions de Giroll, j'ai demandé à Nicolas Derive - un des rares Ubuntu Members français, et accessoirement Girollien - quelles étaient les limites de l'hébergement de projet sur le Launchpad.
Sur la page de création d'un nouveau projet (il faut peut-être identifié pour la voir, je ne l'assure pas), il est précisé :
Donc d'après le titre, il faut que ce soit un projet open source. Mais plus bas, après de nombreux détails, on peut voir, dans le choix des licences disponibles :
Ainsi on a le droit de choisir entre autres une licence propriétaire ?
Nicolas me signale aussi que l'on peut restreindre l'accès à un dépôts bazaar aux personnes d'une team, de même pour les rapports de bugs.
Donc la question que je me pose : j'ai un projet professionnel développé en PHP5, pas spécialement propriétaire mais en tout cas pas open source non plus (quand même un projet commercial à la base). Je me sers de Bazaar pour gérer les versions car j'apprécie la possibilité de commiter en étant hors-ligne.
Puis-je légalement utiliser le Launchpad pour un projet pro non open source, restreindre l'accès aux sources et aux bugs à une team qui ne comporte que moi et éventuellement deux ou trois contacts ?
Je ne compte pas le faire, mais c'est une question que je me pose. Dans la logique je trouverais étrange que ce soit possible mais au fond pourquoi pas ?
Vous avez une réponse et/ou une opinion, ça m'intéresse ?
Est-ce possible d'utiliser le launchpad pour un projet professionnel non open-source ? via BastNic
J'utilise au quotidien l'excellent gestionnaire de versions (VCS) nommé Bazaar.
Cette application est omniprésente dans le monde ubuntero car c'est le VCS supporté par défaut par Launchpad, la méga plateforme permettant de gérer la communauté, les bugs, les spécifications, les traductions d'Ubuntu.
Launchpad est une EXCELLENTE plateforme pour gérer tout ça.
Ce soir à l'une des réunions de Giroll, j'ai demandé à Nicolas Derive - un des rares Ubuntu Members français, et accessoirement Girollien - quelles étaient les limites de l'hébergement de projet sur le Launchpad.
Sur la page de création d'un nouveau projet (il faut peut-être identifié pour la voir, je ne l'assure pas), il est précisé :
Donc d'après le titre, il faut que ce soit un projet open source. Mais plus bas, après de nombreux détails, on peut voir, dans le choix des licences disponibles :
Ainsi on a le droit de choisir entre autres une licence propriétaire ?
Nicolas me signale aussi que l'on peut restreindre l'accès à un dépôts bazaar aux personnes d'une team, de même pour les rapports de bugs.
Donc la question que je me pose : j'ai un projet professionnel développé en PHP5, pas spécialement propriétaire mais en tout cas pas open source non plus (quand même un projet commercial à la base). Je me sers de Bazaar pour gérer les versions car j'apprécie la possibilité de commiter en étant hors-ligne.
Puis-je légalement utiliser le Launchpad pour un projet pro non open source, restreindre l'accès aux sources et aux bugs à une team qui ne comporte que moi et éventuellement deux ou trois contacts ?
Je ne compte pas le faire, mais c'est une question que je me pose. Dans la logique je trouverais étrange que ce soit possible mais au fond pourquoi pas ?
Vous avez une réponse et/ou une opinion, ça m'intéresse ?
jeudi, juin 14 2007
Utilisation de bazaar par l'exemple, mise en place d'un répertoire partagé de travail sur Code Igniter via Administrateur
Bazaar est un gestionnaire de version, un VCS en anglais : Version Control System.
Si jamais vous ignorez ce qu'est un gestionnaire de version je ne peux que vous conseiller de vous renseigner sur ce qu'est un gestionnaire de version (la définition sur Wikipedia). Si vous développez souvent et que vous n'en utilisez pas, je vous recommande de lire cet article.
Il existe beaucoup de VCS concurrents de Bazaar : mercurial, CVS, SVN. Le plus connu est certainement svn, je l'utilise moi-même beaucoup car il est très utilisé sur les divers projets auxquels je participe. Je privilégie le 3/4 du temps bazaar, mais ce n'est pas toujours moi qui initie les projets donc...
Bazaar est très à la mode en ce moment car il est très utilisé dans le monde ubuntero. Il est même intégré au célèbre Launchpad. Parmi les nombreuses super fonctionnalités, celles que j'apprécie particulièrement sont :
- la simplicité de mise en place comparée à svn... Il y a peu de temps j'ai essayé de le faire utilisé par un ami, mais malgré le super tutoriel de David Larlet... il a raté (il est loin d'être débutant pourtant).
- l'utilisation hors-ligne, chacun fait ses commit dans son coin puis on regroupe le tout.
Il est donc très bien intégré à Ubuntu et est très simple à installer :
sudo aptitude install bzr
Si jamais vous voulez une interface graphique pour vous en servir, il existe une interface GTK :
sudo aptitude install bzr-gtk
Mon projet
J'ai sous le coude au moins un projet à développer à l'aide du framework PHP Code Igniter. Ce projet va être développé à plusieurs, pour l'instant nous sommes deux et d'ici moins d'une semaine nous serons trois. Il est impossible de coder quelque chose à plusieurs sans gestionnaire de version.
Le deuxième avantage cité tout à l'heure est sympa dans ce cas présent étant donné que toutes les personnes qui vont travailler sur le projet n'ont pas tout le temps accès au serveur de l'entreprise.
je rappelle mon précédent article sur Code Igniter qui vous expliquait comment je hiérarchise mes répertoires. Le projet présenté ici est de rentre mon installation de Code Igniter versionnable.
J'ai donc un dossier nommé codeigniter à la racine de mon répertoire personnel dans lequel on trouve :
* application-test-1 * application-test-2 * bambooinvoice. * projet-a-realiser * ci_default_application * ci_system * ci_user_guide
Je ne veux pas me répéter, mais cette configuration me permet, pour une seule copie des fichiers systèmes (ci_system), d'avoir un nombre quelconques d'applications.
Côte-à-côte nous avons donc les applications d'exemples, de tests, voir bambooinvoice (un des plus gros exemples concret de CodeIgniter). J'aime beaucoup travailler ainsi.
Mise en place de bazaar sur notre projet
Revenons dans notre dossier de tout-à-l'heure et initialisons le projet :
bzr init
Le dossier contient maintenant un dossier de plus :
* .bzr * application-test-1 * application-test-2 * bambooinvoice. * application-excellent-exemple * projet-a-realiser * ci_system * ci_user_guide
L'initialisation de bazaar dans le dossier nous crée un dossier .bzr dans lequel on trouve tout ce qui permet de gérer les différentes versions... Pour l'instant il ne contient pas grand chose car nous n'avons pas encore validé le contenu ("commit" en anglais).
bzr status
nous indique qu'il existe un certain nombre de fichiers inconnus, ajoutons les via la commande
bzr add
puis validons les changements avec
bzr commit -m "premier versement"
Il vous sera demandé d'ajouter une explications aux changements effectués. Pour une première initialisation j'ajouterais simplement "premier versement". Vous venez de créer la première révision de votre projet.
Publier votre projet
Le dépôt est prêt. Mais plusieurs cas de figures se présentent...
- si vous êtes le seul à travailler dessus et que vous n'avez qu'une seule machine alors c'est bon, vous n'avez rien à faire, juste des commit de temps en temps et votre projet sera enregistré aux moments clés de leurs avancements. Si jamais vous faites de grosses erreurs vous pourrez revenir en arrière...
- vous avez votre base de travail sur votre ordinateur et vous désirez publiez votre travail sur une machine que nous appellerons "serveur" qui sera le point central de tous les travaux (c'est ce que propose le launchpad).
Nous allons nous attarder sur le deuxième cas, donc comment envoyer votre travail sur le serveur, comment récupérer ce qui a été modifié par les autres personnes travaillant sur le projet.
Avec la commande précédente bzr commit, vous avez créé la première révision... Plaçons la sur la machine serveur. Je suppose ici que nous allons passer par du ftp sécurisé (sftp), et que le répertoire sur lequel nous allons placer le projet est /home/bast/Codeigniter (il faut noter l'adresse absolue sinon ça ne marche pas).
bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Maintenant vous pouvez travailler en local, faire vos commit de temps en temps.. Mais vous resterez en local. Quand vous voudrez publier votre travail, il faudra suivre un cycle de commande :
bzr merge bzr commit bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Le bzr merge permet de synchroniser le travail en local et sur le serveur, le bzr commit valide les changements dus aux merge, et enfin on publie tout via bzr push.
Récupérer le projet
C'est extrêmement simple et très proche de la commande précédente pour envoyer tout sur le serveur :
bzr branch sftp://<utilisateur sur le serveur>@<monserveur><chemin absolu>
On récupère ainsi la dernière branche du serveur (dernière version du projet courant). Ensuite pour pouvoir travailler dessus et publier son travail, et bien il suffit de faire comme le point précédent, merge, commit et push.
Autre commandes utiles
bzr log
... pour voir l'historique de toutes les modifications
bzr revert -r <un numero de version>
... pour revenir à une version précédente
bzr help <commande>
... pour plus d'information sur une commande bzr, par exemple bzr help revert vous donnera la documentation et des exemples sur l'utilisation de la commande revert.
Conclusion
Voila un premier tutoriel...
Rien de vraiment exhaustif, il manque un gros tas de commande mais je voulais juste montrer un cas concret : ce qui va être utile à mes collaborateurs les mois à venir.
Pour une documentation plus 'documentation', je vous conseille ces quelques excellents liens issus de la documentation francophone de bazaar :
Utilisation de bazaar par l'exemple, mise en place d'un répertoire partagé de travail sur Code Igniter via BastNic
Bazaar est un gestionnaire de version, un VCS en anglais : Version Control System.
Si jamais vous ignorez ce qu'est un gestionnaire de version je ne peux que vous conseiller de vous renseigner sur ce qu'est un gestionnaire de version (la définition sur Wikipedia). Si vous développez souvent et que vous n'en utilisez pas, je vous recommande de lire cet article.
Il existe beaucoup de VCS concurrents de Bazaar : mercurial, CVS, SVN. Le plus connu est certainement svn, je l'utilise moi-même beaucoup car il est très utilisé sur les divers projets auxquels je participe. Je privilégie le 3/4 du temps bazaar, mais ce n'est pas toujours moi qui initie les projets donc...
Bazaar est très à la mode en ce moment car il est très utilisé dans le monde ubuntero. Il est même intégré au célèbre Launchpad. Parmi les nombreuses super fonctionnalités, celles que j'apprécie particulièrement sont :
- la simplicité de mise en place comparée à svn... Il y a peu de temps j'ai essayé de le faire utilisé par un ami, mais malgré le super tutoriel de David Larlet... il a raté (il est loin d'être débutant pourtant).
- l'utilisation hors-ligne, chacun fait ses commit dans son coin puis on regroupe le tout.
Il est donc très bien intégré à Ubuntu et est très simple à installer :
sudo aptitude install bzr
Si jamais vous voulez une interface graphique pour vous en servir, il existe une interface GTK :
sudo aptitude install bzr-gtk
Mon projet
J'ai sous le coude au moins un projet à développer à l'aide du framework PHP Code Igniter. Ce projet va être développé à plusieurs, pour l'instant nous sommes deux et d'ici moins d'une semaine nous serons trois. Il est impossible de coder quelque chose à plusieurs sans gestionnaire de version.
Le deuxième avantage cité tout à l'heure est sympa dans ce cas présent étant donné que toutes les personnes qui vont travailler sur le projet n'ont pas tout le temps accès au serveur de l'entreprise.
je rappelle mon précédent article sur Code Igniter qui vous expliquait comment je hiérarchise mes répertoires. Le projet présenté ici est de rentre mon installation de Code Igniter versionnable.
J'ai donc un dossier nommé codeigniter à la racine de mon répertoire personnel dans lequel on trouve :
* application-test-1 * application-test-2 * bambooinvoice. * projet-a-realiser * ci_default_application * ci_system * ci_user_guide
Je ne veux pas me répéter, mais cette configuration me permet, pour une seule copie des fichiers systèmes (ci_system), d'avoir un nombre quelconques d'applications.
Côte-à-côte nous avons donc les applications d'exemples, de tests, voir bambooinvoice (un des plus gros exemples concret de CodeIgniter). J'aime beaucoup travailler ainsi.
Mise en place de bazaar sur notre projet
Revenons dans notre dossier de tout-à-l'heure et initialisons le projet :
bzr init
Le dossier contient maintenant un dossier de plus :
* .bzr * application-test-1 * application-test-2 * bambooinvoice. * application-excellent-exemple * projet-a-realiser * ci_system * ci_user_guide
L'initialisation de bazaar dans le dossier nous crée un dossier .bzr dans lequel on trouve tout ce qui permet de gérer les différentes versions... Pour l'instant il ne contient pas grand chose car nous n'avons pas encore validé le contenu ("commit" en anglais).
bzr status
nous indique qu'il existe un certain nombre de fichiers inconnus, ajoutons les via la commande
bzr add
puis validons les changements avec
bzr commit -m "premier versement"
Il vous sera demandé d'ajouter une explications aux changements effectués. Pour une première initialisation j'ajouterais simplement "premier versement". Vous venez de créer la première révision de votre projet.
Publier votre projet
Le dépôt est prêt. Mais plusieurs cas de figures se présentent...
- si vous êtes le seul à travailler dessus et que vous n'avez qu'une seule machine alors c'est bon, vous n'avez rien à faire, juste des commit de temps en temps et votre projet sera enregistré aux moments clés de leurs avancements. Si jamais vous faites de grosses erreurs vous pourrez revenir en arrière...
- vous avez votre base de travail sur votre ordinateur et vous désirez publiez votre travail sur une machine que nous appellerons "serveur" qui sera le point central de tous les travaux (c'est ce que propose le launchpad).
Nous allons nous attarder sur le deuxième cas, donc comment envoyer votre travail sur le serveur, comment récupérer ce qui a été modifié par les autres personnes travaillant sur le projet.
Avec la commande précédente bzr commit, vous avez créé la première révision... Plaçons la sur la machine serveur. Je suppose ici que nous allons passer par du ftp sécurisé (sftp), et que le répertoire sur lequel nous allons placer le projet est /home/bast/Codeigniter (il faut noter l'adresse absolue sinon ça ne marche pas).
bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Maintenant vous pouvez travailler en local, faire vos commit de temps en temps.. Mais vous resterez en local. Quand vous voudrez publier votre travail, il faudra suivre un cycle de commande :
bzr merge bzr commit bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Le bzr merge permet de synchroniser le travail en local et sur le serveur, le bzr commit valide les changements dus aux merge, et enfin on publie tout via bzr push.
Récupérer le projet
C'est extrêmement simple et très proche de la commande précédente pour envoyer tout sur le serveur :
bzr branch sftp://<utilisateur sur le serveur>@<monserveur><chemin absolu>
On récupère ainsi la dernière branche du serveur (dernière version du projet courant). Ensuite pour pouvoir travailler dessus et publier son travail, et bien il suffit de faire comme le point précédent, merge, commit et push.
Autre commandes utiles
bzr log
... pour voir l'historique de toutes les modifications
bzr revert -r <un numero de version>
... pour revenir à une version précédente
bzr help <commande>
... pour plus d'information sur une commande bzr, par exemple bzr help revert vous donnera la documentation et des exemples sur l'utilisation de la commande revert.
Conclusion
Voila un premier tutoriel...
Rien de vraiment exhaustif, il manque un gros tas de commande mais je voulais juste montrer un cas concret : ce qui va être utile à mes collaborateurs les mois à venir.
Pour une documentation plus 'documentation', je vous conseille ces quelques excellents liens issus de la documentation francophone de bazaar :
Utilisation de bazaar par l'exemple, mise en place d'un répertoire partagé de travail sur Code Igniter via BastNic
Bazaar est un gestionnaire de version, un VCS en anglais : Version Control System.
Si jamais vous ignorez ce qu'est un gestionnaire de version je ne peux que vous conseiller de vous renseigner sur ce qu'est un gestionnaire de version (la définition sur Wikipedia). Si vous développez souvent et que vous n'en utilisez pas, je vous recommande de lire cet article.
Il existe beaucoup de VCS concurrents de Bazaar : mercurial, CVS, SVN. Le plus connu est certainement svn, je l'utilise moi-même beaucoup car il est très utilisé sur les divers projets auxquels je participe. Je privilégie le 3/4 du temps bazaar, mais ce n'est pas toujours moi qui initie les projets donc...
Bazaar est très à la mode en ce moment car il est très utilisé dans le monde ubuntero. Il est même intégré au célèbre Launchpad. Parmi les nombreuses super fonctionnalités, celles que j'apprécie particulièrement sont :
- la simplicité de mise en place comparée à svn... Il y a peu de temps j'ai essayé de le faire utilisé par un ami, mais malgré le super tutoriel de David Larlet... il a raté (il est loin d'être débutant pourtant).
- l'utilisation hors-ligne, chacun fait ses commit dans son coin puis on regroupe le tout.
Il est donc très bien intégré à Ubuntu et est très simple à installer :
sudo aptitude install bzr
Si jamais vous voulez une interface graphique pour vous en servir, il existe une interface GTK :
sudo aptitude install bzr-gtk
Mon projet
J'ai sous le coude au moins un projet à développer à l'aide du framework PHP Code Igniter. Ce projet va être développé à plusieurs, pour l'instant nous sommes deux et d'ici moins d'une semaine nous serons trois. Il est impossible de coder quelque chose à plusieurs sans gestionnaire de version.
Le deuxième avantage cité tout à l'heure est sympa dans ce cas présent étant donné que toutes les personnes qui vont travailler sur le projet n'ont pas tout le temps accès au serveur de l'entreprise.
je rappelle mon précédent article sur Code Igniter qui vous expliquait comment je hiérarchise mes répertoires. Le projet présenté ici est de rentre mon installation de Code Igniter versionnable.
J'ai donc un dossier nommé codeigniter à la racine de mon répertoire personnel dans lequel on trouve :
* application-test-1 * application-test-2 * bambooinvoice. * projet-a-realiser * ci_default_application * ci_system * ci_user_guide
Je ne veux pas me répéter, mais cette configuration me permet, pour une seule copie des fichiers systèmes (ci_system), d'avoir un nombre quelconques d'applications.
Côte-à-côte nous avons donc les applications d'exemples, de tests, voir bambooinvoice (un des plus gros exemples concret de CodeIgniter). J'aime beaucoup travailler ainsi.
Mise en place de bazaar sur notre projet
Revenons dans notre dossier de tout-à-l'heure et initialisons le projet :
bzr init
Le dossier contient maintenant un dossier de plus :
* .bzr * application-test-1 * application-test-2 * bambooinvoice. * application-excellent-exemple * projet-a-realiser * ci_system * ci_user_guide
L'initialisation de bazaar dans le dossier nous crée un dossier .bzr dans lequel on trouve tout ce qui permet de gérer les différentes versions... Pour l'instant il ne contient pas grand chose car nous n'avons pas encore validé le contenu ("commit" en anglais).
bzr status
nous indique qu'il existe un certain nombre de fichiers inconnus, ajoutons les via la commande
bzr add
puis validons les changements avec
bzr commit -m "premier versement"
Il vous sera demandé d'ajouter une explications aux changements effectués. Pour une première initialisation j'ajouterais simplement "premier versement". Vous venez de créer la première révision de votre projet.
Publier votre projet
Le dépôt est prêt. Mais plusieurs cas de figures se présentent...
- si vous êtes le seul à travailler dessus et que vous n'avez qu'une seule machine alors c'est bon, vous n'avez rien à faire, juste des commit de temps en temps et votre projet sera enregistré aux moments clés de leurs avancements. Si jamais vous faites de grosses erreurs vous pourrez revenir en arrière...
- vous avez votre base de travail sur votre ordinateur et vous désirez publiez votre travail sur une machine que nous appellerons "serveur" qui sera le point central de tous les travaux (c'est ce que propose le launchpad).
Nous allons nous attarder sur le deuxième cas, donc comment envoyer votre travail sur le serveur, comment récupérer ce qui a été modifié par les autres personnes travaillant sur le projet.
Avec la commande précédente bzr commit, vous avez créé la première révision... Plaçons la sur la machine serveur. Je suppose ici que nous allons passer par du ftp sécurisé (sftp), et que le répertoire sur lequel nous allons placer le projet est /home/bast/Codeigniter (il faut noter l'adresse absolue sinon ça ne marche pas).
bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Maintenant vous pouvez travailler en local, faire vos commit de temps en temps.. Mais vous resterez en local. Quand vous voudrez publier votre travail, il faudra suivre un cycle de commande :
bzr merge bzr commit bzr push sftp://<utilisateur sur le serveur>@<monserveur>/home/bast/Codeigniter
Le bzr merge permet de synchroniser le travail en local et sur le serveur, le bzr commit valide les changements dus aux merge, et enfin on publie tout via bzr push.
Récupérer le projet
C'est extrêmement simple et très proche de la commande précédente pour envoyer tout sur le serveur :
bzr branch sftp://<utilisateur sur le serveur>@<monserveur><chemin absolu>
On récupère ainsi la dernière branche du serveur (dernière version du projet courant). Ensuite pour pouvoir travailler dessus et publier son travail, et bien il suffit de faire comme le point précédent, merge, commit et push.
Autre commandes utiles
bzr log
... pour voir l'historique de toutes les modifications
bzr revert -r <un numero de version>
... pour revenir à une version précédente
bzr help <commande>
... pour plus d'information sur une commande bzr, par exemple bzr help revert vous donnera la documentation et des exemples sur l'utilisation de la commande revert.
Conclusion
Voila un premier tutoriel...
Rien de vraiment exhaustif, il manque un gros tas de commande mais je voulais juste montrer un cas concret : ce qui va être utile à mes collaborateurs les mois à venir.
Pour une documentation plus 'documentation', je vous conseille ces quelques excellents liens issus de la documentation francophone de bazaar :
