Pour savoir quel outil choisir vous devez connaitre leurs différences
Avec un DVCS, les branches sont incontournables.
Les branches sont les propriétés exclusives de chaque développeur.
Lorsque tu clones ou que tu te synchronises une archive, tu récupères les branches des autres mais tu ne dois pas travailler dans leurs branches car ces outils ne gèrent pas la concurrence d'accès à une branche. Tu dois donc forcément te créer une branche (ou un fork avec Mercurial) pour travailler puis merger le travail des autres dans ta propre branche. Chaque développeur est donc propriétaire d'une branche et la version de réference correspond à celle d'un unique intégrateur. C'est pourquoi on parle de modèle user-centric par rapport à repository-centric. Dans la pratique il est possible de pusher dans la branche des autres mais c'est avec le risque d 'avoir 2 versions différentes au lieu d'une seule HEAD.
Les outils centralisés gèrent la concurrence au niveau d'une branche au moment du commit. Il n'y a tjs qu'un HEAD mais il faut merger dans son worspace pour commiter si des versions intermédaires ont été commtées depuis le dernier update.
Le modèle DVCS ne prend pas en charge le schéma de concurrence pessimiste (lock/modify/unlock) et si ton projet comporte beaucoup de type de fichiers non mergeables (modèles UML fragmentés, artworks, XML, ...) ou que les développeurs préfèrent cette approche, les DVCS ne sont pas une bonne idée.
De même, l'intégration continue est plus complexe avec les DVCS puisque chacun bosse dans sa branche et qu'un integrateur est nécessaire.
C'est possible de le faire mais plus complexe.
Autre différence les DVCS ne suppportent pas les partial checkout. On ne peut pas extraire de sou-partie d'un projet mais ca n'est pas un problème puisque le checkout est très rapide (en local)
Les DVCS sont aussi très appréciables pour leur performances (Tout est en local et seules les synchro d'archives nécessitent des comms).
Il est aussi possible de commiter plusieurs change request en étant déconnecté.
Enfin leur gestion des branches est à des lieues de ce qu'est et ne sera pas SVN avant un moment.
SVN ne supporte pas le "true rename" et c'est repoussé sans arrêt.
La mémoire de merge n'est pas encore au point. http://subversion.tigris.org/issues/show_bug.cgi?id=898 http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Quel developpeur Eclipse n'appréhende pas le refactoring dans une branche
qui pourrira toutes les autre branches au moment du merge.
Il n'a souvent pas d'autre choix que de refaire le refactoring à la main dans chaque branche. On comprend que ca dissuade de brancher trop souvent.
Ceci est une époque révolue avec les DVCS qui sont basés sur des DAGs
Bref si pour vous les schéma de lock et l'intégration continue priment, gardez SVN sinon sautez le pas , d'autant que ca peut se faire en douceur car tous les DVCS savent se connecter à un depôt SVN.
A ma connaissance Bazaaar est le seul outils libre a supporter ces 2 modes nativement mais au prix d'une certaine lenteur par rapport à ces concurrents DVCS
# DVCS vs VCS
Posté par nomorepost . En réponse au message Quel SCM ?. Évalué à 5.
Avec un DVCS, les branches sont incontournables.
Les branches sont les propriétés exclusives de chaque développeur.
Lorsque tu clones ou que tu te synchronises une archive, tu récupères les branches des autres mais tu ne dois pas travailler dans leurs branches car ces outils ne gèrent pas la concurrence d'accès à une branche. Tu dois donc forcément te créer une branche (ou un fork avec Mercurial) pour travailler puis merger le travail des autres dans ta propre branche. Chaque développeur est donc propriétaire d'une branche et la version de réference correspond à celle d'un unique intégrateur. C'est pourquoi on parle de modèle user-centric par rapport à repository-centric. Dans la pratique il est possible de pusher dans la branche des autres mais c'est avec le risque d 'avoir 2 versions différentes au lieu d'une seule HEAD.
Les outils centralisés gèrent la concurrence au niveau d'une branche au moment du commit. Il n'y a tjs qu'un HEAD mais il faut merger dans son worspace pour commiter si des versions intermédaires ont été commtées depuis le dernier update.
Le modèle DVCS ne prend pas en charge le schéma de concurrence pessimiste (lock/modify/unlock) et si ton projet comporte beaucoup de type de fichiers non mergeables (modèles UML fragmentés, artworks, XML, ...) ou que les développeurs préfèrent cette approche, les DVCS ne sont pas une bonne idée.
De même, l'intégration continue est plus complexe avec les DVCS puisque chacun bosse dans sa branche et qu'un integrateur est nécessaire.
C'est possible de le faire mais plus complexe.
Autre différence les DVCS ne suppportent pas les partial checkout. On ne peut pas extraire de sou-partie d'un projet mais ca n'est pas un problème puisque le checkout est très rapide (en local)
Les DVCS sont aussi très appréciables pour leur performances (Tout est en local et seules les synchro d'archives nécessitent des comms).
Il est aussi possible de commiter plusieurs change request en étant déconnecté.
Enfin leur gestion des branches est à des lieues de ce qu'est et ne sera pas SVN avant un moment.
SVN ne supporte pas le "true rename" et c'est repoussé sans arrêt.
La mémoire de merge n'est pas encore au point.
http://subversion.tigris.org/issues/show_bug.cgi?id=898
http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Quel developpeur Eclipse n'appréhende pas le refactoring dans une branche
qui pourrira toutes les autre branches au moment du merge.
Il n'a souvent pas d'autre choix que de refaire le refactoring à la main dans chaque branche. On comprend que ca dissuade de brancher trop souvent.
Ceci est une époque révolue avec les DVCS qui sont basés sur des DAGs
Bref si pour vous les schéma de lock et l'intégration continue priment, gardez SVN sinon sautez le pas , d'autant que ca peut se faire en douceur car tous les DVCS savent se connecter à un depôt SVN.
A ma connaissance Bazaaar est le seul outils libre a supporter ces 2 modes nativement mais au prix d'une certaine lenteur par rapport à ces concurrents DVCS
Good Luck