Nous migrons de ClearCase à un autre VCS (probablement soit SVN, soit mercurial). Pour les entreprises qui ont fait cette transition, quels facteurs ont-ils trouvé important dans la sélection d'un autre outil VCS et quelles pratiques ont-elles trouvé la transition?
7 Réponses :
Vous devez prendre en compte plusieurs critères tels que:
en termes de
Sinon (base ClearCase), vous devez déterminer quelle partie de l'histoire que vous avez vraiment besoin d'importer.
Un couple à ajouter sont:
+1 doit être d'accord avec le meilleur soutien de la fusion à la fois dans Git et Mercurial
svn et mercurial sont tous deux bon SCM. De nombreux projets OpenSource les utilisent. Si votre choix ne se réparait que sur ces deux alors ce que vous et votre équipe devez prendre en compte:
Comment voulez-vous faire les commits et ramifiants? Distribué ou purement centralisé? Ceci est également lié à la politique de la société. Allez avec SVN si vous voulez que tout soit centralisé. Mais cela ne signifie pas que vous ne pouvez pas avoir de référentiel central avec Mercurial. C'est assez bénéfique si votre équipe choisit des DVC comme Mercurial parce que:
Autre que cela, les deux sont vraiment bons car ils ont tous deux de bonnes performances, de bon support Windows ( SVN < / a>, HG ) et bonne documentation / livre ( svn , HG < / a>).
+1 De nombreuses personnes ne comprennent pas que simplement parce que DVCS n'a pas besoin d'un serveur central qu'il ne peut en avoir un. Quand ils se rendent compte que la fusion fonctionne mieux lorsqu'un représentant central n'est pas nécessaire, ils ont tendance à venir.
soutien tiers. Le système a-t-il un fournisseur de SCC mature pour Visual Studio? (SVN Oui, HG n'est pas mature).
Eclipse? Les deux ont un bon soutien.
Vos développeurs sont-ils utilisés pour être des commandos de ligne de commande? Ensuite, le support / plugins tiers peut être un non-problème.
En général, j'irais toujours avec le système de contrôle de version distribué (DVC). Je n'ai pas essayé mercurial mais git; Mais la prémisse ici est la même.
Si vous utilisez un système centralisé, vous êtes lié à cette structure. Si vous utilisez un système distribué, vous n'êtes pas. Mais juste parce que vous pouvez le distribuer, vous n'êtes pas obligé. Si cela a plus de sens dans votre équipe d'avoir un seul référentiel central, faites-le ainsi.
Ce que vous ne devez pas sous-estimer est le pouvoir des branches locales. La ramification dans un système centralisé est plutôt encombrante, les branches de développeurs ou de fonctionnalités sont rarement faites. Les développeurs ont plutôt plusieurs copies de travail ou conservent des modifications dangereuses de leur copie de travail, de ne pas casser la construction. Avec un système décentralisé, le développeur crée une branche locale qui fonctionne. Interrompu par un bogue SHOW BOPPER, il retourne à la branche principale corrige le problème, appuie les modifications apportées au référentiel central et retourne à sa branche de fonctionnalité. Le flux de travail est extrêmement lisse.
En outre, la nature distribuée du système le rend une robuste. Si le serveur est en panne, il s'agit d'une entreprise comme d'habitude pour les développeurs, ils peuvent même échanger leurs changements entre eux.
Enfin, les développeurs peuvent prendre le travail à la maison, dans l'avion, dans le train ou où tout ce qu'ils aiment. Ils ne perdent jamais la capacité de la VCS et peuvent faire des engagements appropriés.
Le résultat est que le comportement des développeurs en ce qui concerne les VCS est défini par la stratégie de la société et non la technologie et vous pouvez modifier votre stratégie à tout moment.
Si vous migrez à l'écart de Good-Ol ClearCase ;-) Jetez un coup d'œil rapide au SCM en plastique. La plupart des concepts de base seront toujours là, mais tous les bits douloureux sont partis. Et il est distribué. Vérifiez le lien suivant: http://codicesoftware.blogspot.com/2010/03/ distribué-développement-for-windows.html
C'est un vieux fil, mais je voulais contribuer un peu. Imo, svn a couru ce cours. Maintenant, en toute justice, si vous avez environ 50 utilisateurs et que vous ne faites pas beaucoup de branchement, alors sûr, cela ne sera pas pire que cc. Cependant, aussi vieux que cc est et aussi complexe que possible, il a toujours beaucoup de fonctionnalités matures. Donc, si vous êtes une boutique de CC mature, SVN ne répondra pas à vos besoins. En fait, une meilleure pratique consiste à brancher moins et à travailler sur le coffre principal. Donc, un meilleur choix (compte tenu des choix ci-dessus) serait HG. En outre, je suis biaisé vers DVCS. Véritables DVCS qui sont ... et il n'y a que 2 choix OSS: hg et git. et actuellement un système commercial, SCM en plastique. Si vous êtes utilisé pour une représentation visuelle de votre historique de fichier (navigateur VTREE ou un navigateur d'arborescence de composants dans CC UCM, pensez que c'est ce qu'on appelle), le plastique peut être un choix plus viable. Comme je l'ai vu, il a le vtree graphique et autre chose, comme l'explorateur d'arbres de branche. Je me souviens de soutenir CC où beaucoup d'entre nous deviendront à tour de rôle sur le tableau blanc et tiraient le modèle "Process". Le plastique a-t-il intégré. Quoi qu'il en soit, je suis encore biaisé vers DVCs ... J'ai assez souffert de SVN et de CC et d'essayer d'utiliser des outils de réplication coûteux et des scripts de maîtrise. DVCS est si simple! Si vous êtes une boutique de DRUNE DIRELLE / UNIX DEV, GIT peut être un meilleur choix. Si plus de fenêtres ou d'un mélange, HG et plastique ressemblent à de meilleurs choix. Plus de graphiques et de visuels avec du plastique. Je pense que HG manque beaucoup de contrôles de permission et d'accès que vous êtes habitué à CC ... Donc, le plastique pourrait avoir le bord ici. J'espère que cela vous aidera et bonne chance!