Chez nous le passage de CVS s'est fait sans douleur. Nous étions habituée a avoir un serveur central, une branche de dev, des branches pour les releases avec des tags (beta, rc et stables).
Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
C'est le meme fonctionnement que CVS, tres simple.
Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).
[^] # Re: Comment faire du développement dans l'industrie avec SGVD ?
Posté par gS . En réponse à la dépêche Nouvelle version de Bazaar, le DVCS de Canonical. Évalué à 3.
Bzr peut s'utiliser de cette façon, nous avons un repository central qui comme sous CVS, contient un cerrtain nombre de branches, tags, bref, c'est la référence. Au quotidien, les devs on des checkouts fait a partir du repo central et font un 'bind' sur ce dernier.
Cela permet de faire des commits en meme temps sur sa branche locale et sur la base centrale.
C'est le meme fonctionnement que CVS, tres simple.
Si un dev travaille en déplacement ou qu'il n' a pas acces a la base centrale, il fait un unbind et bosse localement.
Lorqu'il revient, il synchronise sa branche locale avec la base centrale, on reste en permanence synchronisé avec les autres via un bzr update (comme CVS), bref tres simple, et les conflits sont notifiés et doivent êtres résolus avant de commiter.
Il arrive aussi que des devs sur des truc expérimentaux se détachent de la base centrale et ne se synchronisent qu'entre eux (un unbind pour se détacher et re-bind avec l'autre dev, c'est pratique).
Bref, je ne sais pas trop si ca répond a ta question mais c'est un exemple d'utilisation qui fonctionne très bien en entreprise (ou le cycle de dev est rigoureux, on travaille dans le biomedical).