Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Et pourtant mon "système" (1 branche par développeur + 1 pour l'intégration) a déjà été largement adopté dans le monde de l'industrie.
Ca s'appelle UCM (Unified Change Management). Il s'agit d'une surcouche à Clearcase qui s'inscrit dans la démarche RUP d'IBM Rational.
La branche (stream) d'intégration répertorie les baselines stables de la release courante du projet.
Chaque developpeur prend en charge une ou plusieurs demandes de changements et les réalise dans sa branche propre. Lorsqu'il souhaite récupérer les dernières avancées stables (baseline) il effectue un "rebase" qui est en fait un merge amélioré de la branche d'intégration vers sa propre branche.
Lorsqu'il a completé un certain nombre de changements, il les "delivre", c'est à dire qu'il effectue ou demande qu'on effectue un merge de sa branche vers celle d'intégration en ne prenant en compte que les changeset correspondant au demandes qu'il souhaite livrer.
S'il souhaite développer une nouvelle fonctionnalité dans sa branche à partir d'un changement qui est n'est pas encore integré dans la branche principale rien ne l'en empêche.
Le fait que la branche du developpeur soit sur un serveur distant ou en local n'affecte en rien le modèle.Il est de toute façon possible de deporter une branche sur un autre site avec Clearcase (Multisite).Ceci est d'ailleurs dynamique (transfert des droits d'ecriture sur la branche ) et différe des modèles décentralisé type Arch. (je peux developper si ca t'interesse)
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Ici tu soulignes le fait de travailler en mode pull.
En décentralisé type Arch, un membre autorisé de l'archive centrale peut faire un pull de la branche du contributeur sans le déclarer puis merger la branche rapatriée sur la principale. En mode gestion centralisée, le contributeur doit être déclaré et travailler sur une autre branche du serveur ou une branche déportée.
Je conviens que cette facilité corresponde mieux au dev Open Source type Linux. En entreprise, l'intêret est beaucoup moindre puisque tout contributeur est connu et qu'on doit tracer les changements qui lui sont affectés .
De même en entreprise il est plus fréquent que ce soit le contributeur qui fasse le merge d'integration car c'est lui qui a la meilleur connaissance de ce qu'il touche. L'équipe d'intégration se contente de passer les tests d'integration, d'accepter ou de refuser de promouvoir la baseline.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...)(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Rien n'empêche de faire la même chose en centralisé, du moment que le dev à les prérogatives pour créer un sous-branche.Cette technique s'appelle "branchement par activité". Elle permet entre autre de corriger un bug urgent en repartant d'une baseline antérieure alors que des fonctionnalités moins urgentes ont déjà eté développées.
Désolé pour la réponse fleuve mais tu as abordé un peu tous les sujets.
[^] # Re: Bazaar
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 3.
Maintenant, pour un projet plus important, tu as des tas de cas ou ton système ne marche pas _du tout_. Imagine que tu as une contribution qui n'est pas encore intégrée à la branche officielle (pas encore assez bien testée), mais que tu veuilles déjà développer une deuxième fonctionalité qui l'utilise. Sans gestionaire de versions décentralisé, t'es mal.
Et pourtant mon "système" (1 branche par développeur + 1 pour l'intégration) a déjà été largement adopté dans le monde de l'industrie.
Ca s'appelle UCM (Unified Change Management). Il s'agit d'une surcouche à Clearcase qui s'inscrit dans la démarche RUP d'IBM Rational.
La branche (stream) d'intégration répertorie les baselines stables de la release courante du projet.
Chaque developpeur prend en charge une ou plusieurs demandes de changements et les réalise dans sa branche propre. Lorsqu'il souhaite récupérer les dernières avancées stables (baseline) il effectue un "rebase" qui est en fait un merge amélioré de la branche d'intégration vers sa propre branche.
Lorsqu'il a completé un certain nombre de changements, il les "delivre", c'est à dire qu'il effectue ou demande qu'on effectue un merge de sa branche vers celle d'intégration en ne prenant en compte que les changeset correspondant au demandes qu'il souhaite livrer.
S'il souhaite développer une nouvelle fonctionnalité dans sa branche à partir d'un changement qui est n'est pas encore integré dans la branche principale rien ne l'en empêche.
Le fait que la branche du developpeur soit sur un serveur distant ou en local n'affecte en rien le modèle.Il est de toute façon possible de deporter une branche sur un autre site avec Clearcase (Multisite).Ceci est d'ailleurs dynamique (transfert des droits d'ecriture sur la branche ) et différe des modèles décentralisé type Arch. (je peux developper si ca t'interesse)
Autre exemple:
- Bonjour, voici ma contribution (cf. patch joint)
- J'y comprends rien à ton patch, coupe moi-ça en morceaux plus petits qu'on puisse s'y retrouver (réponse assez fréquente de Torvalds parait-il).
- Ben, euhhh
Ici tu soulignes le fait de travailler en mode pull.
En décentralisé type Arch, un membre autorisé de l'archive centrale peut faire un pull de la branche du contributeur sans le déclarer puis merger la branche rapatriée sur la principale. En mode gestion centralisée, le contributeur doit être déclaré et travailler sur une autre branche du serveur ou une branche déportée.
Je conviens que cette facilité corresponde mieux au dev Open Source type Linux. En entreprise, l'intêret est beaucoup moindre puisque tout contributeur est connu et qu'on doit tracer les changements qui lui sont affectés .
De même en entreprise il est plus fréquent que ce soit le contributeur qui fasse le merge d'integration car c'est lui qui a la meilleur connaissance de ce qu'il touche. L'équipe d'intégration se contente de passer les tests d'integration, d'accepter ou de refuser de promouvoir la baseline.
En un autre pour la forme:
- Voilà, j'ai fait pleins d'améliorations pour le logiciel XYZ. Ma branche est ici: http://toto.com/branche(...)(...)
- Ah, tes patches 1, 12 et 42 m'ont l'air pas mal, je les intègre. Tes patches 33, 34 et 52 ont l'air pas mal, mais il y a X et Y qui ne vont pas. Les autres patches, j'en veux pas.
- OK, je viens de créer une branche ( http://toto.com/monautrebranche/(...)(...) ), j'ai pris seulement les patches 33, 34 et 52, et j'ai corrigé les problèmes X et Y. Ça va maintenant ?
Rien n'empêche de faire la même chose en centralisé, du moment que le dev à les prérogatives pour créer un sous-branche.Cette technique s'appelle "branchement par activité". Elle permet entre autre de corriger un bug urgent en repartant d'une baseline antérieure alors que des fonctionnalités moins urgentes ont déjà eté développées.
Désolé pour la réponse fleuve mais tu as abordé un peu tous les sujets.