Je vais essayer de répondre en partie à ton cahier des charges qui est plutôt garni.
J'ajouterai 2 outsiders que sont Bazaar et Mercurial et j'ignorerai CVS
Ton workflow:
- on commit régulièrement dans la mainline pour les dev en cours
- si une feature est impactante, on créé une branche que l'on maintient à jour à coup de merge
- on merge sur la mainline quand le dev est fini.
- on créé une branche de release quand le code est pret à être livré.
- les bug fix sont appliqués sur la branche de release et sur la mainline.
Tous les VCS supportent ton workflow à priori mais SVN a quelques limitations.
Il ne supporte pas les merges cycliques comme ca:
B T
|<-|
|->|
|<-|
|->|
Dans ton cas tu ne merges que dans un sens (release vers mailine) et au pire une fois dan l'autre sens pour réintegrer un bugfix:
|<-|
|<-|
|<-|
|->|
Avec SVN le dernier merge se fait avec l'option réintégrate et la branche doit être killée.
Autre limitation, si tu branche une fois tu ne dois JAMAIS refaire un cp entre les 2 branches depuis un sous-répertoire sous peine de faire mumuse avec les mergeinfo
Enfin bon courage pour suivre un changeset losrque tu a fait un mv : http://linuxfr.org/comments/1204996.html#1204996
Centralisé
======
A vérifier mais hormis les VCS purement centralisés, le seul DVCS qui supporte ce mode est Bazaar
Par centralisé, j'entends le fait de pouvoir commiter directement dans la branche centrale sur un serveur et si une version concurrente sur cette branche a été commitée, tu en es empêché jusqu'à ce que tu résolves le conflit et que tu retentes ta chance (schema de concurrence optimiste)
Pour les autres (Hg et Git) c'est un peu différent mais il faut comprendre qu'on y arrive très bien sinon il ne serait pas possible de faire de l'intégration continue avec les DVCS.
Le principe est qu'on travaille dans sa propre branche et que par defaut le commit distant est séparé en 2 étapes: 1 commit local + 1 push.
Il est toujours possible d'enchaîner ces 2 étapes en une même transaction et c'est au niveau du serveur (au moment du push) qu'est géré le fait d'accepter ou non le changeset car il n'y pas d'édition concurrente.
Avec Git, on a des vraies branches, le push est refusé si le changement que tu commites n'est pas une feuille (l'ancêtre de ton changement a déjà un autre fils) auquel cas tu dois resoudre le conflit (equivalnt du svn resolve) dans ta branche et retenter.
Avec Hg c'est un peu comme monotone. Les branches ne sont qu'une commodité et un noeud peut avoir plusieurs fils sans pb.
Par défaut, tu peux toujours commiter ou pusher (à vérifier) même si tu as plusieurs heads. Tu as une commande qui détecte le fait que tu as plusieurs
Si tu veux bloquer, il faut installer un hook sur le serveur (je crois).
Ce qu'il faut retenir c'est que le commit local est quand même un avantage lorsque tu es déconnecté et que tu veux par exemple prendre en charge plusieurs bugs request à la suite et les commiter séparément (merge par la suite) et c'est aussi transparent qu'un VCS centralisé si tu associes commit+push en une seule commande.
En revanche ce que ne permettent pas les DVCS c'est le lock pessimiste (le checkout reserved ala Clearcase puisque tu connais)
Ceci peut parfois s'avérer utile pour les utilisateurs qui ont des besoins très limité ou lorsque les fichiers traités sont inadaptés pour les merges. (modèles UML fragmentés dans Eclipse par exemple)
Avec SVN, tu t'en sors en placant les fichiers en lecture seule et avec une propertie svn:needs-lock.
# Quelques éléments
Posté par El Titi . En réponse au journal Recherche gestionnaire de version idéal. Évalué à 6.
J'ajouterai 2 outsiders que sont Bazaar et Mercurial et j'ignorerai CVS
Ton workflow:
- on commit régulièrement dans la mainline pour les dev en cours
- si une feature est impactante, on créé une branche que l'on maintient à jour à coup de merge
- on merge sur la mainline quand le dev est fini.
- on créé une branche de release quand le code est pret à être livré.
- les bug fix sont appliqués sur la branche de release et sur la mainline.
Tous les VCS supportent ton workflow à priori mais SVN a quelques limitations.
Il ne supporte pas les merges cycliques comme ca:
B T
|<-|
|->|
|<-|
|->|
Dans ton cas tu ne merges que dans un sens (release vers mailine) et au pire une fois dan l'autre sens pour réintegrer un bugfix:
|<-|
|<-|
|<-|
|->|
Avec SVN le dernier merge se fait avec l'option réintégrate et la branche doit être killée.
Autre limitation, si tu branche une fois tu ne dois JAMAIS refaire un cp entre les 2 branches depuis un sous-répertoire sous peine de faire mumuse avec les mergeinfo
Enfin bon courage pour suivre un changeset losrque tu a fait un mv :
http://linuxfr.org/comments/1204996.html#1204996
Centralisé
======
A vérifier mais hormis les VCS purement centralisés, le seul DVCS qui supporte ce mode est Bazaar
Par centralisé, j'entends le fait de pouvoir commiter directement dans la branche centrale sur un serveur et si une version concurrente sur cette branche a été commitée, tu en es empêché jusqu'à ce que tu résolves le conflit et que tu retentes ta chance (schema de concurrence optimiste)
Pour les autres (Hg et Git) c'est un peu différent mais il faut comprendre qu'on y arrive très bien sinon il ne serait pas possible de faire de l'intégration continue avec les DVCS.
Le principe est qu'on travaille dans sa propre branche et que par defaut le commit distant est séparé en 2 étapes: 1 commit local + 1 push.
Il est toujours possible d'enchaîner ces 2 étapes en une même transaction et c'est au niveau du serveur (au moment du push) qu'est géré le fait d'accepter ou non le changeset car il n'y pas d'édition concurrente.
Avec Git, on a des vraies branches, le push est refusé si le changement que tu commites n'est pas une feuille (l'ancêtre de ton changement a déjà un autre fils) auquel cas tu dois resoudre le conflit (equivalnt du svn resolve) dans ta branche et retenter.
Avec Hg c'est un peu comme monotone. Les branches ne sont qu'une commodité et un noeud peut avoir plusieurs fils sans pb.
Par défaut, tu peux toujours commiter ou pusher (à vérifier) même si tu as plusieurs heads. Tu as une commande qui détecte le fait que tu as plusieurs
Si tu veux bloquer, il faut installer un hook sur le serveur (je crois).
Ce qu'il faut retenir c'est que le commit local est quand même un avantage lorsque tu es déconnecté et que tu veux par exemple prendre en charge plusieurs bugs request à la suite et les commiter séparément (merge par la suite) et c'est aussi transparent qu'un VCS centralisé si tu associes commit+push en une seule commande.
En revanche ce que ne permettent pas les DVCS c'est le lock pessimiste (le checkout reserved ala Clearcase puisque tu connais)
Ceci peut parfois s'avérer utile pour les utilisateurs qui ont des besoins très limité ou lorsque les fichiers traités sont inadaptés pour les merges. (modèles UML fragmentés dans Eclipse par exemple)
Avec SVN, tu t'en sors en placant les fichiers en lecture seule et avec une propertie svn:needs-lock.
Bon je poursuis dans un autre post.