web-dev-qa-db-fra.com

Avantages / inconvénients de ClearCase

Parce que j'ai du mal à apprendre IBM Rational ClearCase, j'aimerais connaître votre opinion professionnelle.

Je suis particulièrement intéressé par les avantages/inconvénients par rapport à d'autres systèmes de contrôle de version comme Subversion ou Git.

68
B.E.

Vous pouvez trouver une bonne comparaison entre ClearCase et Git dans ma réponse SO:
" Quels sont les concepts de base de ClearCase que chaque développeur doit connaître? ", illustrant quelques différences majeures (et quelques lacunes de ClearCase)


Opérations centrées sur les fichiers

L'inconvénient le plus important de ClearCase est son ancienne approche " centrée sur les fichiers " (par opposition à " référentiel - centrique "comme dans SVN ou Git ou Perforce ...)
Cela signifie que chaque extraction ou enregistrement s'effectue fichier par fichier. L'atomicité de l'opération est au niveau du fichier.
Combinez cela avec un protocole très détaillé et un réseau avec potentiellement plusieurs nœuds entre le poste de travail développeur et le VOB serveur, et vous pouvez vous retrouver avec un serveur de fichiers assez lent et inefficace (dont ClearCase est à la base).

Les opérations fichier par fichier signifient: opérations lentes récursives (comme extraction récursive ou récursif "ajouter à la source) control " , même par clearfsimport).
Un réseau local rapide est obligatoire pour atténuer les effets secondaires de ce protocole de discussion.

VCS centralisé

L'autre aspect à prendre en compte est son aspect centralisé (même s'il peut être "distribué" avec son multi-site répliqué VOB fonctionnalité)
Si le réseau ne permet pas d'accéder aux VOB, les développeurs peuvent:

  • fonctionnent toujours dans les vues instantanées (mais uniquement avec les fichiers piratés)
  • attendre la restauration du réseau s'ils utilisent des vues dynamiques

Option VCS distribuée coûteuse

Vous pouvez avoir une fonctionnalité VCS distribuée en répliquant un Vob.
Mais:

  • vous avez besoin d'un type de licence spécial pour y accéder.
  • cette licence est chère et ajoute au coût de la licence régulière
  • tout vob qui utilise le vob répliqué (admin vob, admin pvob, ...) doit également être répliqué (ce qui signifie que certains projets non directement concernés par un développement distribué devront toujours payer une licence multisite ...)

GUI ancienne et peu conviviale

  • l'interface graphique est très ancienne et peu pratique (look MFC du milieu des années 90, interface graphique complètement synchrone, ce qui signifie que vous devez attendre un rafraîchissement avant de cliquer ailleurs): lorsque vous parcourez les lignes de base, vous ne pouvez pas en rechercher rapidement un en particulier.
  • l'interface graphique sous Unix n'est pas exactement la même que sous Windows (la dernière version 7.1 est meilleure mais pas encore là)
  • le processus d'installation est assez compliqué (bien que le dernier Installer Manager introduit par CC7.1 soit maintenant une interface graphique cohérente sur Windows ou Unix et simplifie la procédure)
  • la seule véritable application riche n'a été développée que pour CCRC (le client distant)

Incohérences et cohérence des UCM

Comme mentionné dans "Comment tirer parti des fonctionnalités de ClearCase", les vues dynamiques sont excellentes (un moyen de voir les données à travers le réseau sans avoir à les copier sur le disque), mais la caractéristique principale reste [~ # ~] ucm [~ # ~] : cela peut être un réel atout si vous avez un gros projet avec un workflow complexe.

Quelques lacunes à cet égard:

Politiques limitées avec Base ClearCase

Utiliser ClearCase sans utiliser UCM signifie devoir définir une politique pour:

  • créer une branche (sinon tout le monde peut créer n'importe quelle branche, et vous vous retrouvez avec un gazillon d'entre eux, avec un cauchemar de fusion de workflow)
  • mettre des étiquettes (sinon vous oubliez d'étiqueter certains fichiers, ou vous mettez une étiquette là où vous n'étiez pas censé, ou vous "déplacez" (halètement) un libellé d'une version à une autre: au moins les lignes de base UCM ne peuvent pas être déplacées)
  • définir changeset . Les ChangeSets existent uniquement avec les activités UCM. Avec Base ClearCase, vous êtes réduit à intelligent "cleartool find "demandes ...

Aucun droit de candidature

La gestion des droits ClearCase est entièrement basée sur les droits système.
Cela signifie que vous devez enregistrer votre utilisateur dans le bon groupe de systèmes, ce qui n'est pas toujours facile à faire lorsque vous devez saisir un ticket pour votre service informatique afin qu'ils puissent effectuer l'enregistrement approprié.
Ajoutez à cela un environnement hétérogène (utilisateurs sous Windows et serveur sous Unix), et vous devez enregistrer votre utilisateur sous Unix en tant que ainsi que Windows! (avec le même nom de connexion/groupe). Sauf si vous mettez une sorte de correspondance LDAP entre les deux mondes (comme Centrify )

Aucune API avancée

  • seule CLI est complète ("cleartool" est l'interface de ligne de commande ClearCase), ce qui signifie que tout script (en Perl ou dans un autre langage) consiste à analyser la sortie de ces commandes cleartool)
  • ClearCase Automation Library (CAL) existe, mais est assez limité
  • L'API Java existe, mais uniquement pour les vues Web pour le client CCRC.

Afficher les stockages pas facilement centralisés/sauvegardés

Les stockages de vues sont l'équivalent du ".svn" de Subversion, sauf qu'il n'y a qu'un "stockage de vues" par vue au lieu de plusieurs .svn dans tous les répertoires d'un espace de travail Subversion. Ça c'est bon.

Ce qui est mauvais, c'est que chaque opération dans une vue (un simple "ls", extraction, vérification, ...) déclenchera un réseau demande au processus view_server qui gère votre serveur de vue.
2 options:

  • déclarez votre stockage de vues sur votre poste de travail: idéal pour l'évolutivité, vous pouvez avoir autant de vues que vous le souhaitez sans taxer le LAN: toutes les communications se font directement sur votre poste de travail. MAIS si cette machine meurt sur vous, vous perdez vos vues .
  • déclarez votre stockage de vues sur un serveur centralisé: cela signifie que tous les processus view_server y seront créés et que toutes les opérations sur une vue par n'importe quel utilisateur devront communiquer avec ce serveur. Cela peut être fait si l'infrastructure est "correcte" (LAN spécial haute vitesse, serveur dédié, surveillance constante), mais en pratique, votre LAN ne prend pas en charge ce mode.

Le premier mode signifie: vous devez sauvegarder vous-même votre travail en cours (fichiers privés ou fichiers extraits)
Le deuxième mode signifie: votre poste de travail peut être indisponible, vous pouvez simplement vous connecter à un autre et récupérer vos vues (sauf pour les fichiers privés d'une vue instantanée)


Discussion parallèle sur les vues dynamiques :

Pour ajouter à l'aspect "vue dynamique", il a un avantage (c'est dynamique) et un défaut (c'est dynamique).
Les vues dynamiques sont idéales pour définir un environnement simple pour partager rapidement un développement petit entre une équipe petite: pour un petit effort de développement, un la vue dynamique peut aider 2 ou 3 développeurs à rester constamment en contact les uns avec les autres, en voyant instantanément quand son commit casse quelque chose dans les autres vues.
Pour un effort de développement plus complexe, l '"isolation" artificielle fournie par la vue d'instantané est préférable (vous ne voyez les changements que lorsque vous actualisez - ou "mettez à jour" - votre vue d'instantané)
Pour de réels efforts ou cours de développement divergents, une branche est toujours requise pour obtenir une véritable isolation du code (des fusions seront nécessaires à un moment donné, que ClearCase gère très bien, quoique lentement, fichier par fichier)

Le fait est que vous pouvez utiliser les deux pour les bonnes raisons.

Remarque: par petite équipe je ne veux pas dire "petit projet". ClearCase est mieux utilisé pour les grands projets , mais si vous souhaitez utiliser des vues dynamiques, vous devez configurer " branches de tâches afin d'isoler un petit effort de développement par branche: de cette façon une "petite équipe" (un sous-ensemble de votre grande équipe) peut travailler efficacement, en partageant rapidement son travail entre ses membres.
.
Ce serait alors une mauvaise utilisation des vues dynamiques, et cela oublierait ses autres utilisations:

  • moyen supplémentaire d'accéder aux données , en plus de vues instantanées, ce qui signifie que c'est un excellent outil pour simplement "voir" les fichiers (vous pouvez par exemple utiliser une vue dynamique pour modifier ses spécifications de configuration jusqu'à ce que vous voyiez ce que vous voulez, puis copier ces règles de sélection dans votre vue instantanée habituelle)
  • une vue latérale pour effectuer des fusions: vous travaillez avec votre vue d'instantané, mais pour les fusions, vous pouvez utiliser votre "sœur-vue" dynamique ("soeur" comme dans "même configuration"), afin d'éviter d'avoir une fusion échouée à cause de des fichiers extraits (sur lesquels vous travailleriez actuellement sur votre vue de capture instantanée) ou à cause d'une vue de capture instantanée pas complètement à jour. Une fois la fusion terminée, vous mettez à jour votre vue d'instantané habituelle et reprenez votre travail.

Développer directement dans une vue dynamique n'est pas toujours la meilleure option car tous les fichiers (non récupérés) sont lus sur le réseau .
Cela signifie que la dll, le jar ou l'exe requis par votre IDE serait accessible via le réseau, ce qui peut ralentir considérablement le processus de compilation.
Solutions possibles:

  • une vue instantanée avec tout en elle
  • une vue instantanée avec dll ou jar ou exe (fichiers qui ne changent pas toutes les cinq minutes: une mise à jour par jour), et une vue dynamique avec seulement les sources visibles.
110
VonC

Le coût est un inconvénient assez évident. Pas seulement le coût de la licence, mais aussi le coût du salaire d'un gourou ClearCase. Presque toutes les entreprises que je connais qui utilisent ClearCase semblent avoir au moins une personne dont le seul but est d'apprivoiser la bête indisciplinée.

Le fait même qu'il soit suffisamment compliqué pour exiger une nounou à temps plein est également inquiétant.

35
Dónal

Un cauchemar absolu d'un système. Cela m'a fait souhaiter que nous puissions revenir à VSS ! (Peu importe tout système de contrôle de source moderne comme Subversion ou Git!)

  • C'est slooooow.
  • Si vous utilisez des vues dynamiques et que le réseau tombe en panne, vous ne pouvez pas accéder à votre copie de travail de la source. Vous ne pouvez rien faire d'autre que asseyez-vous et attendez pour qu'il soit corrigé.
  • Si vous utilisez des vues instantanées , vous semblez rencontrer des conflits et des fichiers "piratés" tout le temps, donc les fichiers de votre copie de travail sont jamais tout à fait le même que dans le dépôt source.
  • Chaque fois que vous essayez une opération grande mise à jour ou livraison, elle invariablement [~ # ~] échoue [~ # ~] pour une raison ou une autre, obligeant votre gourou ClearCase à passer quelques heures/jours à le comprendre. Oh oui, vous devez avoir un gourou ClearCase dédié à plein temps!
  • Quand il échoue, vous souvent ne pouvez pas revenir en arrière l'opération, soit, donc vous êtes coincé avec une opération en cours et les développeurs sont bloqués.
  • Lorsque vous regardez au-delà des jolies icônes (?), Le GUI est très pauvre - jusqu'à des choses comme être incapable de redimensionner les fenêtres pour voir les chemins de fichiers complets!
  • Leur personnel support est assez réticent à réparer quoi que ce soit. Leur première réponse est toujours " c'est par conception" et "pouvez-vous contourner cela?" S'ils fournissent finalement un correctif (après de nombreuses discussions), ce sera le correctif le plus basique possible au problème le plus immédiat.

Fondamentalement, c'est lent, compliqué et peu fiable comme l'enfer. Oh, et ai-je mentionné c'est ridiculement cher? La seule façon dont ils peuvent éventuellement le vendre est de parler à des décideurs qui n'ont jamais utilisé le produit et ne le feront jamais! Je suis sûr qu'aucun développeur au monde ne l'achèterait jamais.

27
EMP

Les validations et les changesets atomiques sont mes plus gros reproches contre ClearCase. Supposons que vous archiviez cinq fichiers dans le cadre d'une correction de bogue ou d'une refactorisation. Ensuite, on découvre que quelque chose a été gâché et que vous devez revenir en arrière. Bonne chance pour trouver quels sont les cinq fichiers et quelle version chacun un doit être activé. Mais prenons un peu de recul. Vous venez de terminer la modification de ces cinq fichiers et il est temps de valider. Les quatre premiers passent très bien. Ce dernier nécessite une fusion massive. Les quatre autres fichiers sont déjà archivés. Ils n'attendent pas que vous ayez terminé les modifications nécessaires dans le dernier fichier. J'espère que personne n'a mis à jour ou n'utilise une vue dynamique. Un serveur de build d'intégration continue va également échouer.

Parfois, nous créons un tout nouveau répertoire plein de fichiers qui doivent être archivés, mais nous ne voulons pas les archiver jusqu'à ce qu'ils soient terminés. Il est tôt et tout est encore volatil, alors pourquoi vérifier les choses que vous pourriez supprimer très bientôt? OK, très bien jusqu'à présent. Il est maintenant temps de vous enregistrer. Vous ajoutez le dossier nouvellement créé au contrôle de code source. Eh bien, ClearCase n'est pas récursif, donc seulement ce dossier single est archivé. Avec SVN, ce dossier et tout ce qui se trouve en dessous est ajouté, comme vous le souhaitez. Le développeur doit se rappeler d'ajouter tout, sinon, beaucoup de fichiers seront manquants.

ClearCase est propriétaire des fichiers et des dossiers, vous ne pouvez donc rien modifier à moins de les avoir préalablement extraits. Le plugin Eclipse enlève beaucoup de nuisance ici. Je ne peux pas vous dire combien de fois j'ai ouvert un fichier dans vi pour effectuer un changement rapide, seulement pour découvrir que j'avais oublié de le vérifier en premier. Le paiement n'est pas non plus récursif.

Les mises à jour peuvent être douloureusement lentes sans changements. Lorsque vous mettez à jour avec une vue instantanée, tous les mises à jour de fichiers, pas seulement les fichiers modifiés. J'ai travaillé sur un projet avec plus de 20 000 fichiers. Je voudrais me connecter à distance à ma machine de travail, démarrer la mise à jour, puis me rendre au travail; prendre du café; aller à mon bureau pendant qu'il finissait. Cela peut sembler exagéré, mais ce n'est malheureusement pas le cas.

Les vues dynamiques sont terribles, sauf si vous êtes dans une très petite équipe. Et si c'est le cas, pourquoi avez-vous même ClearCase? J'ai vu d'innombrables points de vue de personnes se faire arroser parce que quelqu'un a archivé des fichiers qui ont brisé les vues de tout le monde. Vous devez toujours mettre à jour et fusionner tout conflit sur votre propre vue. De cette façon, les changements ne vous concernent que. Avec une vue dynamique, vous ne pouvez pas fusionner avant de remonter; vous vous engagez et espérez.

Je sais que le coût n'est probablement pas une grande préoccupation, mais les développeurs qui font de l'argent pour l'entreprise aimeraient dépenser les 50 000 à 100 000 $ (selon la licence ClearQuest, qui est un ajout courant) pour des événements amusants ou de nouveaux équipements ( chaises, moniteurs, etc.). IBM recommande d'avoir du personnel pour faire fonctionner ClearCase. Pourquoi ne pas redéfinir ces personnes pour générer des revenus pour l'entreprise, au lieu de s'assurer que les choses ne tombent pas en panne et ne brûlent pas?


Certaines des raisons que j'ai entendues pour ne pas changer:

  • L'apprentissage prendra du temps et de l'argent
    • L'apprentissage de SVN ou de Mercurial ne devrait pas prendre plus d'une journée. Seul ClearCase suggère d'avoir un certain rapport entre administrateurs et développeurs.
  • La migration sera douloureuse
  • Sécurité
    • Il n'y a pas de trous béants connus dans SVN AFAIK, et l'équipe de développement se consacre à réparer tout ce qui se trouve rapidement. Le ministère de la Défense semble OK avec SVN.
  • Aucun gain de productivité réel par la suite
    • Il faut une éternité pour essayer de traquer les bogues sans changements. J'adore pouvoir revenir en arrière jusqu'à ce que je ne puisse pas voir le bug. Vous ne pouvez pas faire cela dans ClearCase.
  • Multisite
    • WANdisco résout ce problème. Ce n'est pas gratuit cependant.

La seule chose que ClearCase fait mieux que les autres est de ramifier des fichiers individuels, tout en gardant les autres sur la même piste qu'une autre branche.

25
geowa4

Tout ce que j'ai fait dans Clearcase semble toujours dur. Alors que je n'ai jamais eu cette impression avec d'autres systèmes (sauf peut-être CVS à l'occasion).

J'ai utilisé SVN, CVS, Clearcase et Mercurial.

20
Paul Nathan

Nous migrons simplement de CC vers Git pour la plupart des raisons données ici. Je voudrais ajouter une raison de rester loin de CC ou de tout autre système de contrôle de source commercial.

Vos données commerciales vitales sont les otages de ClearCase. Vous ne pouvez pas le retirer.

Vos données commerciales essentielles sont le code, son historique de version et toutes les métadonnées telles que les commentaires de validation, qui se sont enregistrés et quand.

Tous les logiciels auront une durée de vie limitée. Vous devriez toujours vous demander quand vous introduisez un nouveau système qui avale des données commerciales importantes, que ce soit du code, des bogues, des données client ou autre: comment puis-je récupérer mes données? Si vous ne pouvez pas répondre à cette question, vous ne devez pas introduire ce système.

Lorsque nous avons migré, nous avons perdu la majeure partie de notre histoire et toutes nos métadonnées. Essentiellement, nous n'avons que l'historique correspondant aux versions publiées, mais des informations sur les modifications apportées en réponse aux demandes des clients sont perdues (nous avons ces données dans le système de support client et de ticket de bogue, donc elles ne sont pas complètement perdues, mais le couplage avec le code source a disparu).

Ce sera quelque part entre une nuisance et un problème pour nous à court ou moyen terme. Dans quelques années, ce n'est plus important, mais peut-être que pendant 1 à 3 ans, cela importera.

(Il existe des outils commerciaux pour migrer CC vers d'autres SCM, mais ils n'ont pas été jugés adaptés à nos besoins, et je doute que cela aurait été faisable. L'exportation minimale que nous avons effectuée a pris assez de temps.)

La leçon apprise est la suivante: ne confiez jamais des données commerciales vitales à des systèmes propriétaires.

15
simon

Tout J'ai connu que ClearCase est inefficace, moche, trop complexe, lent, déroutant, cher et peu pratique.

Il semble attirer les gestionnaires et les ingénieurs qui ont tout compris.

Merde, IBM et Rational doivent avoir des vendeurs incroyables pour vendre un produit aussi merdique.

15
Alex Worden

Mon expérience avec ClearCase a été un désastre, et je vais appuyer la déclaration de Don selon laquelle cela nécessite un expert résident - malheureusement, nous en avions plus d'un. J'avais de l'expérience avec CVS ​​et d'autres systèmes de contrôle de version, je connaissais les concepts, mais j'ai trouvé la documentation ClearCase incompréhensible et j'ai dû demander de l'aide plusieurs fois; différents experts m'ont donné des conseils contradictoires au point où nous avons en fait cassé le cd. Autrement dit, après avoir émis une commande ClearCase dans un shell UNIX, la commande "cd" a échoué avec un message d'erreur.

La tâche de base d'un système de contrôle de version est vraiment assez simple. Honnêtement, je pense qu'une demi-douzaine de commandes devraient suffire, en utilisant un schéma de fichiers qui joue bien avec les autres. Pour moi, ClearCase ressemble au résultat d'un responsable marketing compliquant délibérément l'enfer pour rendre le produit sophistiqué et puissant. J'ai entendu dire qu'il peut être configuré pour se comporter de manière simple, sûre et fiable, mais encore une fois, cela nécessite les services d'un expert - prêt à l'emploi, c'est comme un couteau suisse motorisé.

15
Beta

Aucun commit atomique

Une fois que vous avez archivé les fichiers, il est très difficile de revenir à un certain état, car les validations atomiques ne sont pas prises en charge. Lors de l'archivage de plusieurs fichiers, chaque fichier obtient une nouvelle révision (similaire à CVS) et non l'archivage lui-même. Je pense que c'est une fonctionnalité cruciale, car vous ne voulez guère revenir sur des fichiers uniques mais effectuer des actions de validation (qui devraient mapper les tâches). Avec ClearCase, vous ne pouvez revenir à certains états qu'en utilisant des étiquettes. En pratique, l'utilisation d'étiquettes ClearCase pour chaque enregistrement est exagérée et n'est donc pas effectuée.

Interface utilisateur merdique

L'interface graphique de ClearCase Explorer n'est qu'une grosse blague. Horrible dans la convivialité et laid. Des fonctions différentes et souvent nécessaires ne sont pas fournies (par exemple, archivage récursif des artefacts travaillés). L'outil de ligne de commande cleartool utilisé avec cygwin est bien meilleur, mais certaines choses ne sont toujours pas disponibles, comme l'ajout récursif de nouveaux fichiers/dossiers au contrôle de code source. Je dois rire la tête si je lis un script de 50 lignes de long pour contourner ce problème.

Efforts administratifs élevés

Administrer ClearCase beast est loin d'être évident ou léger (à la différence d'autres systèmes scm comme CVS, Subversion ou Git). Attendez-vous à mettre quelques experts ClearCase dédiés pour simplement le faire fonctionner.

Performances horribles

Rien de pire que de faire attendre vos développeurs lors de l'interfaçage avec l'outil SCM, c'est comme conduire avec les freins à main activés. Cela ralentit votre cerveau et votre travail. Obtenir de nouveaux fichiers dans votre vue d'instantané prend environ 30 minutes pour les artefacts 10K. Une mise à jour (aucun artefact n'a été modifié) pour le même montant prend environ 5 minutes. Lorsque vous expérimentez beaucoup et que vous sautez entre différentes vues à jour, cela signifie beaucoup d'attente. Cela devient encore pire lorsque vous travaillez sur des fichiers et que vous souhaitez vous enregistrer ou les mettre à jour. Le départ, l'enregistrement et l'ajout aux cycles de contrôle de la source prennent environ 10 à 15 secondes, ce qui est évidemment un cauchemar. Cela devient très ennuyeux lorsque vous refactorisez le changement de nom ou le déplacement de types ou de méthodes (de nombreux fichiers peuvent être affectés).

Manque de support du développement distribué

Aujourd'hui, le développement de logiciels est souvent une chose distribuée (les développeurs sont répartis dans le monde entier et travaillent sur le même produit/projet). ClearCase ne convient absolument pas à cela, car il est mal adapté au travail hors ligne. Pour effectuer une extraction (action avant de pouvoir modifier un fichier/dossier), vous devez être connecté au réseau. Ici, vous pouvez utiliser l'option Hijack mais c'est plutôt une solution de contournement en tant que fonctionnalité (vous déverrouillez simplement le fichier sur le système de fichiers). Si vos sites de développement sont éloignés de votre serveur ClearCase, la latence de check-in/check-out peut même augmenter si considérablement qu'elle n'est pas utilisable du tout. Il existe des solutions de contournement pour cela, comme l'utilisation de ClearCase Multisite (technologie de réplique scm DB), mais vous devez payer un supplément pour cela et n'est pas trivial à administrer.

Git comme alternative

Bien qu'étant un grand fan + partisan de l'Open Source, je suis toujours prêt à payer de l'argent pour un bon logiciel. Mais en regardant IBM-Monster ClearCase, je n'investirais pas mon argent ici, il a toutes ces lacunes discutées, et de plus IBM ne semble pas investir d'argent pour améliorer leur produit de manière significative. Récemment, j'ai jeté un œil à une scit Git qui a l'air très bien, en particulier pour ses fonctionnalités de branchement + fusion, où ClearCase a ses principaux atouts.

Ces informations proviennent de http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/

14
joe

Peut-être le pire logiciel jamais créé. Je ne travaillerai pour aucune entreprise qui utilise quoi que ce soit de rationnel. Mis à part CC complètement planter et redémarrer fréquemment mon poste de travail sur les builds dynamiques. Que se passe-t-il lorsque vous poussez quelque chose vers le contrôle de code source et que CC fait ce qu'il fait le mieux, planter? Votre code est-il alors mis en perdu + trouvé, sauvegardé quelque part peut-être? Non, c'est parti pour toujours. Donc, si vous êtes dans une situation horrible d'utilisation de ce logiciel géant coûteux, conservez des doublons de tout. Bon travail Rational/IBM. Façon de capturer la partie la plus importante du contrôle de source, la fiabilité. Meurs lentement.

13
Ryan

Inconvénients de ClearCase - un ajout au message le plus détaillé ici.

  1. L'outil de fusion ne vaut pas la peine. Il vous aide à peine, ne se souvient d'aucune décision que vous avez prise, c'est juste un diff glorifié.

  2. L'outil de fusion doit vérifier les répertoires pour même vérifier s'ils ont besoin d'une fusion. C'est un peu fou.

  3. J'utilise BitKeeper au travail (supposons Git), et la fusion de deux référentiels même s'il y a des conflits est si triviale et conviviale même avec la ligne de commande, tandis que ClearCase ayant des tonnes d'outils GUI est un processus long et laborieux qui est également extrêmement sujet aux erreurs .

  4. Tous les outils GUI nécessitent une tonne de latence. Même voir ce qui peut être fait sur un fichier nécessite une connexion haut débit. Ainsi, un clic droit dans l'outil ClearCase sur un fichier travaillant à domicile pourrait prendre une minute ou deux avec un accès Internet haut débit en raison de la quantité extrême de besoins en réseau.

  5. Quelqu'un peut complètement gâcher le référentiel ou les enregistrements s'ils rendent leurs spécifications de vue différentes de celles de l'équipe. Ce qui est assez fou que personne ne puisse vérifier une branche; ils ont besoin de la spécification de vue appropriée qui leur donnera incidemment les bonnes choses. Le concept peut être agréable et flexible, mais dans 99% des cas, il provoque juste beaucoup de douleur. Ai-je mentionné que vous ne pouvez pas envoyer vos spécifications via Microsoft Outlook, car les outils CC n'acceptent pas UTF-8, vous ne pouvez donc pas le copier-coller?

  6. J'ai absolument rien Ravi de dire à propos de CC. Je l'ai utilisé pendant 2 ans dans 2 entreprises et je l'ai laissé tomber en un clin d'œil heureux tout le temps. Il est également impossible de simplement expérimenter à la maison avec vos propres projets, vous apprendrez donc toujours SVN ou Git à la maison et serez obligé de passer par des difficultés ClearCase au travail. Personne que je connais n'a jamais utilisé CC volontairement. Ils ne l'utilisent que parce qu'un gestionnaire au travail a décidé que CC est le chemin du salut et a forcé tout le monde à y migrer. En fait, ma dernière entreprise a migré de CVS vers ClearCase, et après un an de ClearCase à SVN. C'était ça détesté.

  7. ClearCase n'est pas seulement une chose qui vous fait dire non. C'est comme vivre dans une maison infestée de fourmis. Chaque fourmi n'est au mieux qu'un inconvénient mineur, mais l'infestation vous rendra fou.

12
Dmitriy Likhten

J'essaie de consolider quelques commentaires dans un véritable post ici. Je ne suis pas vraiment là pour vous convaincre que l'un est meilleur que l'autre, sauf en faisant quelques remarques:

  • Si vous comparez git et ClearCase, je soumets respectueusement que vous devez mieux définir vos besoins - si vous envisagez ClearCase pour une "bonne" raison, le git n'est probablement même pas dans l'équation - c'est beaucoup trop nouveau pour faire confiance pour le contrôle des sources au niveau de l'entreprise, imo.
  • ClearCase introduit de nombreux concepts dans l'espace de contrôle de version que les autres systèmes n'ont pas, donc cela peut être assez intimidant et déroutant. Surtout si la seule expérience que vous avez est de lire la documentation, comme cela semble être le cas pour quelques personnes ici.
  • ClearCase n'est certainement pas bien adapté aux énormes bases de code prises en charge par les développeurs qui ne sont pas sur un réseau local avec un serveur VOB. Vous pouvez en répliquer plusieurs (multisite) VOB serveurs pour les rapprocher des développeurs distants, mais ce n'est pas nécessairement pratique si ces sites distants ne sont qu'un seul développeur.
  • Voulez-vous le versionnage de fichiers ou le versionnage de référentiel? C'est une question assez importante, et qui filtrera nécessairement tout un ensemble d'outils, ce qui facilitera votre travail. La version du référentiel présente de nombreux avantages (et ce n'est pas "nouveau", comme le prétendent certaines affiches - des outils commerciaux comme Perforce existent depuis plus d'une douzaine d'années, et il peut y avoir des outils qui ont fait la version du référentiel avant même Perforce), mais ce n'est pas une panacée.
  • Avec une installation suffisamment grande de tout système de contrôle de source, vous allez avoir besoin d'aide. Lorsque vous envisagez d'utiliser des outils, vous devez considérer à quel point il sera facile de trouver des personnes pour vous aider (soit des demandeurs d'emploi qui ont de l'expérience, soit des consultants qui seront là à tout moment pour résoudre tout problème). Un système SCM sans maintenance n'existe pas, et en supposant que vous en avez un, vous aurez plus de problèmes que d'en choisir un qui nécessite une administration "trop".
  • Ne prêtez pas trop d'attention aux personnes qui disent à quel point les "vues dynamiques" sont mauvaises - les mauvaises politiques SCM sont mauvaises, quel que soit l'outil que vous utilisez. Vos politiques et pratiques de gestion de la configuration doivent être distinctes de votre choix d'outil - aucun outil n'empêchera les utilisateurs de détruire tout votre code si vous ne définissez pas de politiques de branchement et de fusion sensées. Si quelqu'un suggère que le fait que les développeurs s'engagent directement sur/main soit une idée judicieuse, vous voudrez peut-être vous éloigner de cette conversation.

ClearCase est un bon outil, mais c'est un outil compliqué. Il n'y a pas moyen de contourner cela - il n'a pas de mode "installation facile". :-) D'un point de vue technique, il n'y a rien que git ou SVN puisse faire que ClearCase ne puisse pas (bien que souvent la terminologie soit différente, car les projets Open Source ont tendance à simplement inventer une nouvelle taxonomie là où il en existait déjà une), mais certaines choses sont certainement plus faciles/plus difficile pour un système donné, selon leur conception. Les vues "instantanées" ClearCase sont fondamentalement la même chose que si vous extrayiez un référentiel de SVN ou CVS - il s'agit d'une copie locale du code source sur votre machine, avec des pointeurs vers le serveur central pour des outils permettant d'interroger l'historique des versions, etc. Vous pouvez travailler avec ces vues sans aucune connexion réseau au serveur ClearCase une fois qu'elles ont été créées, et vous pouvez les "recycler" pour éviter de télécharger à nouveau l'intégralité de votre référentiel lorsque vous souhaitez passer à une autre branche, par exemple Exemple. Les "vues dynamiques" sont fondamentalement une invention ClearCase et le mode de fonctionnement standard pour un LAN. Ils ressemblent à l'extraction d'un référentiel SVN, mais ils ne copient aucun fichier tant que vous n'avez pas apporté de modifications. De cette façon, la vue est disponible immédiatement, mais elle ne peut évidemment pas être utilisée si le serveur Clearcase principal n'est pas disponible et est désagréable à utiliser avec une connexion à latence élevée. Ils ont également l'avantage de pouvoir être montés en tant que lecteur réseau sur n'importe quelle machine ayant accès au serveur sur lequel ils ont été créés, donc si votre poste de travail Windows meurt, vous pouvez simplement vous connecter à un autre, monter votre vue et obtenir retour au travail, car tous les fichiers sont stockés soit sur le serveur VOB (pour les fichiers que vous n'avez pas modifiés sur cette branche), soit sur le serveur view_server (pour les fichiers que vous avez créés ou modifiés uniquement dans cette vue).

En outre, et cela mérite son propre paragraphe .... clearmerge vaut presque le prix de l'admission à lui seul. C'est de loin le meilleur outil de fusion que j'ai jamais utilisé dans ma vie. Je crois fermement que de nombreuses mauvaises pratiques dans SCM se sont développées en raison d'un manque d'outils de fusion de haute qualité, de sorte que les utilisateurs de CVS n'ont jamais appris à utiliser correctement les branches et cette peur de la branche s'est propagée à nos jours sans raison particulièrement bonne.

Ok, tout cela étant dit, si vous cherchez des raisons de ne pas utiliser ClearCase, ils ne sont pas difficiles à trouver, même si je pense que ce n'est pas la bonne façon de procéder. Vraiment, vous devriez avoir à trouver de bonnes raisons pour utiliser ClearCase, pas des raisons de NE PAS utiliser ClearCase. Vous devez entrer dans n'importe quelle situation SCM en supposant que ClearCase est trop d'outil ou un outil trop compliqué pour le travail, puis voyez si vous avez une situation qui vous encourage à l'utiliser de toute façon. Avoir des logos IBM ou Rational n'est pas une bonne raison .. :-)

Je ne considérerais même pas ClearCase à moins que vous ne puissiez dire oui à toutes les déclarations suivantes:

  • Vous avez maintenant, ou aurez éventuellement, plus de 50 développeurs travaillant sur la même base de code.
  • La plupart de ces développeurs sont situés au centre ou ont des connexions à haut débit et à faible latence vers un emplacement central.
  • Vous avez un ensemble de politiques SCM et pouvez identifier comment utiliser ClearCase pour appliquer ces politiques (vous devriez vraiment en tenir compte pour tout outil)
  • L'argent n'est vraiment pas un objet
11
Nick Bastin

Mon expérience est principalement limitée par CC, CVS et SVN. En principe, CC est technologiquement capable, prêt pour l'entreprise et comparable par ses fonctionnalités à tout VCS moderne. Mais il a plusieurs défauts qui le rendent inutilisable dans tout environnement orienté vers les personnes. Pour les environnements orientés processus, il est probablement plus approprié, bien que je doute que ces environnements soient appropriés en eux-mêmes. Peut-être, dans les logiciels militaires, cosmiques ou médicaux, je ne sais pas. Quoi qu'il en soit, je pense que même pour ces domaines, il existe des outils appropriés et toujours plus conviviaux.

En plus d'être un VCS techniquement compétent, CC présente plusieurs avantages distinctifs:

  • Vues dynamiques
  • Belle arborescence des versions
  • Déclencheurs
  • Bonne version de fusion, y compris les renommages

À mon avis, leur utilisation est limitée sauf la dernière; et ils ne compensent pas les défauts. Vue dynamique Nice en théorie, mais pas toujours disponible en pratique. L'arbre des versions est beaucoup moins utilisé dans d'autres VCS, bien que nécessaire dans CC en raison de la prolifération des branches (voir 6). Les déclencheurs, comme je le sais, sont très détaillés et capables, mais je pense que pour la plupart des tâches pratiques, les crochets SVN sont assez bons. Et maintenant sur les inconvénients qui concernent principalement la convivialité:

  • CC échoue totalement en termes de convivialité pour le groupe d'utilisateurs principal: pour les développeurs. Et c'est la principale raison pour laquelle je pense qu'il ne devrait jamais être utilisé dans n'importe quel environnement, que ce soit en entreprise ou non. Même s'il était gratuit, il sucerait néanmoins l'argent de votre entreprise en faisant perdre du temps à vos développeurs et en les frustrant. Ce point est composé de:
    1. "Check out-Check In" avec une approche de verrouillage stricte - il est contre-productif, refactoring hostile et dangereux dans les organisations de référentiel avec une seule branche de développement pour plusieurs développeurs. Pendant ce temps, les avantages d'un verrouillage strict sont négligeables.
    2. Mauvaise performance et charge élevée
    3. Il ne peut pas être utilisé à distance sans multisite (en raison de 2). Le multisite coûte aussi cher. Le client ClearCase Remote est très limité. Il n'a même pas cleartool (avant la version 7.1), laissant seul des vues dynamiques.
    4. Il peut difficilement être utilisé hors ligne. Les vues dynamiques ne fonctionnent tout simplement pas. Les vues instantanées sont effectivement en lecture seule, car vous ne pouvez pas extraire sans accès au référentiel (voir 1). Le piratage est une mauvaise option, ce qui signifie en fait que CC renonce à toute responsabilité pour le fichier piraté. Et CC ne peut pas vous montrer de différence avec la révision précédente hors ligne. SVN est capable de montrer la différence avec la révision précédente même en étant hors ligne.
    5. Modèle trop compliqué, en particulier avec UCM: VOB, PVOB, projets, flux, branches, vues, livrer, mettre à jour, charger, restaurer, rebaser, fusionner, ligne de base, archiver, extraire. Je pense que la moitié de ces concepts sont tout simplement superflus et n'ajoutent pas de valeur, tout en augmentant la complexité technique et conceptuelle. Peu de développeurs comprennent même des choses de base sur CC.
    6. Prolifération des branches. Par exemple, le référentiel est souvent organisé avec un flux par développeur (en raison de 1). Cela n'a tout simplement aucun sens dans SVN ou la plupart des autres VCS.
    7. Aucune révision à l'échelle du référentiel. Eh bien, il existe des révisions telles que les comprennent, ils ont appelé des lignes de base. Mais quand je vois une révision de fichier et que je veux obtenir un instantané du référentiel au moment de cette révision de fichier, j'obtiendrai des problèmes. Je devrai faire de la magie noire avec les spécifications de configuration pour créer une vue instantanée ou trouver d'une manière ou d'une autre une vue dynamique si elle est disponible.
    8. Interface utilisateur utilisateur merdique. L'arbre des versions, même étant Nice, a une facilité d'utilisation médiocre. L'outil de fusion est juste dommage. Autres "fonctionnalités": fenêtres non redimensionnables, absence de recherche incrémentielle à certains endroits, interface centrée sur la souris, apparence dans le style de 1995, flux de travail étrange réparti entre le client et l'explorateur de projet, etc.
    9. CC provoque des check-ins rares et vastes. Vous savez tous que les enregistrements doivent être petits et fréquents. Mais les développeurs s'abstiennent généralement d'interactions supplémentaires avec les fichiers CC, Hijack et travaillent dans VCS local ou même sans VCS (ce qui est plus souvent, malheureusement). Et puis, après deux semaines de développement, ils commencent à valider la fonction comlex qui ajoute 20 fichiers et affecte 20 autres fichiers. Cela dure un jour ou deux, car ils ont détourné des fichiers et doivent maintenant effectuer une fusion manuelle avec toutes les nouvelles modifications du repo et résoudre tous les conflits et les divergences. Au cours de ce processus, le code n'est pas compilable, car plusieurs fichiers ont été archivés avec succès et d'autres non. Et après cela, il n'est toujours pas compilable car ils ont oublié d'ajouter 2 autres fichiers à CC.
  • C'est très cher
  • Il est très complexe en termes d'infrastructure et nécessite des administrateurs dédiés
9
Rorick

ClearCase semble extrêmement puissant, de l'extérieur. Mais vraiment, c'est juste que le nombre de commandes et d'options que vous devez utiliser pour le flux de travail de base est si élevé que celles-ci se cachent derrière quelques alias ou scripts, et vous vous retrouvez avec quelque chose de moins puissant que CVS, avec l'utilisabilité de Visual Source Sûr. Et chaque fois que vous voulez faire quelque chose d'un peu plus compliqué que vos scripts ne le permettent, vous ressentez une sensation de malaise à l'estomac.

Comparez cela avec Git, qui semble compliqué de l'extérieur, mais après une semaine de travail avec lui, vous vous sentez complètement en contrôle. Le modèle de référentiel est simple à comprendre et incroyablement puissant. Parce qu'il est facile d'accéder aux écrous et boulons, il est en fait agréable de creuser sous la surface de votre flux de travail quotidien.

Par exemple, trouver une tâche triviale comme comment simplement afficher une version non HEAD d'un fichier dans une vue instantanée m'a pris quelques heures et ce que j'ai fini par être n hack complet . Pas le genre de hack agréable non plus.

Mais dans Git, trouver une tâche apparemment compliquée, comme comment engager interactivement seulement quelques changements, (et laisser le reste pour plus tard) était très amusant, et tout le temps j'ai le sentiment que le VCS me permet d'organiser le code et l'histoire d'une manière qui me convient, plutôt que l'histoire soit un accident de la façon dont nous avons utilisé le VCS. "Git signifie ne jamais avoir à dire 'tu devrais avoir'" .

Dans mon travail, j'utilise Git pour toutes sortes de tâches légères, même dans ClearCase. Par exemple, je fais TDD, et je m'engage à Git chaque fois qu'un tas de tests réussit et que je suis sur le point de refactoriser. Une fois la tâche terminée, je m'enregistre dans ClearCase et Git m'aide à revoir exactement ce que je change. Essayez simplement d'obtenir ClearCase pour produire un diff sur quelques fichiers - ce n'est pas possible! Utilisez Google pour découvrir les différents hacks que les gens ont essayé de contourner. C'est quelque chose que le contrôle de version devrait faire dès le départ, et cela devrait être facile! CVS a cela depuis des décennies!

8
Matt Curtis
  • Cauchemar à administrer dans des environnements sécurisés
  • Une technologie dépassée
  • GUI non intuitive
  • Coûteux
  • Monstre de ressource
  • Vendre à Microsoft

À mon avis? Seule raison de l'avoir? Si vous suivez religieusement RUP.

7
Tom Werner

Le soutien est terrible. Nous avons des billets ouverts depuis des années. Notre gourou Eclipse a en fait corrigé un bogue dans son plugin Eclipse localement en environ 30 minutes en désassemblant le fichier Java. Mais le ticket n'a toujours pas reçu le support de niveau un. De temps en temps, ils essaient pour le fermer sournoisement ou nous le renvoyer "pour essayer la dernière version" (même si nous leur avons envoyé une recette de reproduction qu'ils pourraient essayer par eux-mêmes.).

Ne touchez pas avec un mât de barge.

6
Ealdwulf

Performance.

ClearCase est puissant, stable (SI correctement entretenu et supervisé) mais il est lent. Géologique parfois.

Les vues de vues dynamiques entraînent des temps de construction horribles, les vues instantanées peuvent prendre un certain temps à mettre à jour (pause déjeuner pour les grands projets) ou à la caisse (rentrer à la maison pour la journée).

5
Kristof Provost
4
hawkeye
  • Les développeurs passeront la moitié de leur temps à trouver clearcase avant de faire n'importe quel travail et une fois qu'ils auront compris, ils installeront git localement et ne pousseront que vers le dépôt clearcase si nécessaire.

  • Vous devrez employer un administrateur Clearcase dédié.

4
sashang

Je suggérerais SVN pour le jeu d'outils et Git pour la mise à l'échelle/le flux de travail. Je suggère également d'éviter CC si possible. (Sans compter l'argent, le fait qu'il soit si pénible à utiliser qu'il nécessite un administrateur à temps plein est une blague totale)

3
Matthew Whited

J'ai récemment dû me débattre avec une situation similaire. Vous pouvez peut-être apprendre de mon histoire.

L'équipe à laquelle je venais d'être affecté utilisait un outil lourd de manière compliquée et sujette aux erreurs. J'ai d'abord tenté de les vendre sur mes outils et processus de choix. Cette tentative a lamentablement échoué. J'ai été sidéré qu'ils choisiraient un environnement aussi lourd que celui qui était à la fois plus facile et plus efficace. Il s'avère qu'ils voulaient être disciplinés, et utiliser un processus douloureux leur semblait discipliné. Cela semble bizarre, mais c'est vrai. Ils avaient aussi beaucoup d'autres idées fausses. Après avoir compris ce qu'ils recherchaient, nous sommes restés avec la même suite d'outils (Serena), mais avons massivement changé la configuration.

Mon conseil est de comprendre ce qui compte pour votre équipe. Extraire ClearCase ne vous mènera nulle part à moins que vous ne parliez de leurs intérêts. Découvrez également pourquoi ils ne veulent pas utiliser d'alternatives. Fondamentalement, faites un peu de collecte des exigences et adaptez vos choix d'outils à vos besoins. Selon vos options, qui sait, Clear Case peut finalement être la meilleure option.

3
Darryl

Je ne suis pas totalement contre ClearCase (il a ses avantages), mais pour énumérer les inconvénients:

  • Limitations de licence - Je ne peux pas travailler facilement depuis mon domicile, car je n'ai pas accès au serveur de licences. Même avec une vue instantanée sur mon ordinateur portable, je dois jouer des tours parce que je ne peux pas obtenir de licence. Il existe un client distant spécial, mais ajoute des tonnes de ses propres limitations au mix
  • Limitations de licence à nouveau - Seulement autant de sièges à contourner, et personne ne peut l'utiliser.
  • Outils Unix obsolètes - ClearCase semble fonctionner mieux sur les systèmes Unix, mais les outils GUI sont nulles. L'intégration Windows/Unix de ClearCase introduit toutes sortes de ses propres problèmes.
2
Chris Arguin
  1. pas d'enregistrement atomique

À partir de la nouvelle version de la version 7.1 CC, le check-in atomique est une fonctionnalité SI vous le souhaitez. Personnellement, je n'en voudrais vraiment pas, mais apparemment, certaines personnes y voient "une caractéristique essentielle". Je ne voudrais JAMAIS un gros volume en une seule fois comme une sorte de version massive. Là encore ... si vous le voulez, allumez-le.

donc ... plus un argument.

1
edelwater

Nous utilisons UCM ClearCase intégré à ClearQuest (système de suivi/modification de DR) depuis 4 ans avec plus de 50 développeurs. Nous avons plus de 50 projets UCM sur des milliers de flux qui ont traité plus de 35 000 DR et demandes de changement. Au cours de cette période, nous avons officiellement effectué plus de 600 livraisons d'intégration et tout en ayant jusqu'à 6 efforts de développement et de publication simultanés.

Je suis le gars principal de CM/ClearCase avec une sauvegarde qui est capable d'effectuer les builds de livraison/fusion et d'intégration réguliers. Le réseau et les serveurs sont pris en charge par l'équipe informatique. Tout ce que je peux dire, c'est que nous n'avons eu pratiquement aucun problème venant du côté CM de cet énorme effort de développement et que nous n'avons jamais été un frein au spectacle. Nos développeurs ont été formés uniquement avec les éléments de base et des étapes simples leur ont été données à chaque fois qu'un nouveau projet (branche) était créé à la demande de la direction du projet.

Trop de développeurs se sont plaints de ClearCase car ils ne disposent pas du support CM/IT/ClearCase/Process/Management approprié. Les développeurs doivent se concentrer sur le développement et non SCM ou être un spécialiste des outils. Pour un développement logiciel de grande envergure, au moins 5 à 7% du budget doit être consacré au support CM et aux outils.

1
dave

ClearCase est parfaitement utilisable si vous êtes prêt à utiliser également un autre système de contrôle de version! personnellement, je trouve que l'utilisation de Mercurial ontop of CC fonctionne assez bien.

1
Arthur Ulfeldt

Le plus gros inconvénient pour moi est à la fois les performances (surtout si votre VOB est multisite ou hors site), et les temps d'arrêt potentiellement longs.

Si vous êtes comme moi et travaillez dans un bureau relativement petit au sein d'une grande entreprise (sans informatique sur site), les serveurs Clearcase en panne peuvent vous coûter la meilleure partie d'une journée de travail en non-productivité et trouver les bonnes personnes pour le réparer.

En fin de compte, utilisez-le uniquement si vous en avez vraiment besoin pour ce que vous faites et assurez-vous d'avoir un budget informatique costaud pour le maintenir.

1
Erik Kerber

Exécuter un JDK à partir d'un VOB sous Linux.

Essayez-le, vous devez jouer avec la variable LD_PRELOAD (je sais!)

0
Spedge

le point "il faut une personne dédiée" et "c'est compliqué" etc ....

Le problème principal ici pour trouver ce problème est que vous devez définir si vous voulez que la gestion de la configuration soit effectuée dans votre organisation (ce qui n'est PAS la gestion des versions). La gestion de la configuration est comme la gestion de projet: même sans outil, vous pouvez toujours gérer le projet et sans outil, vous pouvez faire la gestion de la configuration. Beaucoup de gens ont du mal à comprendre cela et beaucoup de gens pensent que la gestion de la configuration est égale à un outil qui versionne des sources de logiciels ou quelque chose ...... (donc des comparaisons avec des sous-versions ou d'autres systèmes de gestion de VERSION)

ClearCase est une solution conçue pour être utilisée dans un environnement de gestion de configuration ERGO: il y a un gestionnaire de configuration (tout comme "il y a un gestionnaire de projet").

Donc ... si, selon vous, cette personne dévouée est là pour gérer un outil, je pense qu'il y a quelque chose de très mal. À mon avis, il y a une personne dédiée qui gère la configuration qui, du point de vue de l'utilisateur final, ne se présente qu'en cas de problème avec l'outil, mais considère cela comme seulement 1% de son travail.

Donc, ce que vous devez faire (comme dans tout autre projet logiciel), revenez à vos exigences et compilez une liste d'exigences sur ce que votre organisation veut avec la gestion de la configuration. ET OUI, comme dans tout autre projet logiciel, vous aurez des utilisateurs (comme par exemple des développeurs) qui ne sont pas du tout d'accord avec d'autres utilisateurs (comme par exemple la gestion) sur certaines exigences. Là réside l'imho clé sur certaines réactions que j'ai lues ici.

Et à mon humble avis si vous avez la liste des exigences de l'organisation ET un gestionnaire de configuration dans le mélange .... le choix est assez clair (voir aussi le forum sur www.cmcrossroads.com)

ClearCase n'est pas un outil uniquement pour les utilisateurs finaux entrant leurs sources sous contrôle de version comme Subversion ou git. C'est seulement 1% de la raison pour laquelle un gestionnaire de configuration veut vraiment un outil de gestion de configuration mature.

Et ... Je pense que le choix d'un système CM ne devrait jamais incomber aux développeurs comme choisir le bon outil de gestion de projet ou le bon système CRM. Les développeurs sont des utilisateurs finaux d'une certaine partie des fonctionnalités de l'outil.

0
edelwater