Avantages/inconvénients de ClearCase [closed]
parce que je me bats actuellement pour apprendre IBM ClearCase rationnel, j'aimerais entendre votre opinion professionnelle.
je suis particulièrement intéressé par les avantages/désavantages par rapport à D'autres systèmes de contrôle de version comme Subversion ou Git.
30 réponses
vous pouvez trouver une bonne comparaison entre ClearCase et Git dans ma réponse SO:
" Quels sont les concepts ClearCase de base que chaque développeur devrait connaître? ", illustrant quelques différences majeures (et quelques défauts de ClearCase)
opérations centrées sur les fichiers
le défaut le plus important de ClearCase est son ancienne " approche (par opposition à repository - centric " comme dans SVN ou Git ou Perforce...)
Cela signifie que chaque check-out ou check-in est fait fichier par fichier. Le atomicité de fonctionnement est au niveau du dossier.
Combinez cela avec un protocole très verbeux et un réseau avec potentiellement plusieurs noeuds entre la station de travail du développeur et le serveur VOB, et vous peut finir avec un serveur de fichiers assez lent et inefficace (dont ClearCase est au cœur).
Fichier-par-les opérations de fichier signifie: "151990920 lente" récursive (comme extraction récursive ou récursive "ajouter à la source" , voire par clearfsimport
).
Un fast LAN est obligatoire pour atténuer les effets secondaires de ce protocole chatty.
Centralized VCS
l'autre aspect à prendre en compte est son aspect centralisé (bien qu'il puisse être "distribué" avec sa fonction VOB répliquée sur plusieurs sites)
Si le réseau ne permet pas l'accès aux VOBs, les développeurs peuvent:
- fonctionne toujours dans les vues instantanées (mais avec des fichiers détournés seulement)
- attendre la restauration de la réseau s'ils utilisent des vues dynamiques
Cher VCS Distribués option
vous pouvez avoir une fonction VCS distribuée en répliquant un Vob.
Mais:
- vous avez besoin d'une licence spéciale pour y accéder.
- cette licence est coûteuse et ajoute au coût de la licence régulière
- tout vob qui utilise le vob répliqué (admin vob, admin pvob,...) doivent également être reproduits (ce qui signifie que certains projets qui ne sont pas directement concernés par un développement distribué devront encore payer une licence multi-sites...)
Vieux et pas d'interface utilisateur graphique conviviale
- L'interface graphique est très ancienne et peu pratique (mid-90's MFC look, GUI complètement synchrone, ce qui signifie que vous devez attendre un rafraîchissement avant de cliquer ailleurs): lors de la navigation baselines, vous ne pouvez pas rapidement chercher un en particulier.
- L'interface graphique D'Unix n'est pas exactement la même que sous Windows (la dernière version de 7.1 est meilleure, mais pas encore là)
- le processus d'installation est assez compliqué (bien que le dernier installateur Gestionnaire introduit par CC7.1 est maintenant une interface graphique cohérente sur Windows ou Unix et simplifie la procédure)
- la seule application vraiment riche n'a été développée que pour le CCRC (le client éloigné)
UCM incohérences et dans des rapports de cohérence
comme mentionné dans "comment tirer parti des fonctionnalités de ClearCase ", les vues dynamiques sont excellentes (une façon de voir les données à travers le réseau sans avoir à les copier sur le disque), mais la caractéristique principale reste UCM : il peut être un véritable atout si vous avez un gros projet avec un workflow complexe.
quelques lacunes sur ce avant:
- les dépendances entre les composants ne sont pas bien gérées pour une profondeur supérieure à un (à cause du bug de" parasite baseline ")
- UCM a encore quelques coherencies et incohérences comme documentée dans cm Crossroads
Limitée politiques avec la Base de ClearCase
utiliser ClearCase sans utiliser UCM signifie avoir à définir une politique pour:
- créer branche (sinon n'importe qui peut créer n'importe quelle branche, et vous finissez avec un gazillon d'entre eux, avec la fusion de flux de travail cauchemar)
- put labels (sinon vous oubliez d'étiqueter certains fichiers, ou vous mettez une étiquette là où vous n'étiez pas supposé le faire, ou vous "déplacez" (gasp) une étiquette d'une version à une autre: à moins UCM lignes de base ne peut pas être déplacé)
- définir changeset . Les changements n'existent qu'avec les activités de L'UCM. Avec Base ClearCase, vous êtes réduit à des requêtes intelligentes "
cleartool find
"...
Pas de droits sur l'application
la gestion des droits ClearCase est entièrement construite sur les droits du système.
Cela signifie que vous devez enregistrer votre utilisateur au bon groupe de système, qui n'est pas toujours facile à faire, vous devez entrer un billet à votre service afin de faire le bon d'inscription.
Ajoutez à cela un environnement hétérogène (utilisateurs sur Windows, et serveur sur Unix), et vous devez enregistrer votre utilisateur sur Unix ainsi que Windows! (avec le même login/nom de groupe). Sauf si vous mettez une sorte de correspondance LDAP entre les deux monde (comme Centrify )
Pas de API avancée
- seul CLI est complet ("
cleartool
"est L'Interface en ligne de commande ClearCase), ce qui signifie que tout script (en Perl ou dans un autre langage) consiste à analyser la sortie de cescleartool
commandes) - ClearCase Automation Library (CAL) existe, mais est assez limitée L'API Java
- existe, mais uniquement pour les vues web pour le client CCRC.
voir les entrepôts pas facilement centralisés/sauvegardés
Le point de Vue de stockages sont l'équivalent de la ".svn "de SubVersion, sauf qu'il n'y a qu'un seul" stockage de vue " par vue au lieu de beaucoup .svn dans tous les répertoires D'un espace de travail SubVersion. Ce qui est bon.
ce qui est mauvais est que chaque opération dans une vue (un simple " ls
", checkout, checking, ...) va déclencher une réseau demande à view_server processus qui gère votre serveur de vue.
2 options:
- déclarez votre stockage de vue sur votre poste de travail: idéal pour l'évolutivité, vous pouvez avoir autant de vue que vous le voulez sans taxer le LAN: toutes les communications sont faites directement sur votre poste de travail. Mais si cette machine meurt sur vous, vous perdez vos vues .
- déclare le stockage de votre vue 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 un utilisateur devront communiquer avec ce serveur. Cela peut être fait si l'infrastructure est "correcte" (réseau local spécial à grande vitesse, serveur dédié, surveillance constante), mais en pratique, votre réseau local ne supporte pas ce mode.
le premier mode signifie: Vous devez sauvegarder vous-même votre travail en cours (fichiers privés ou cochés)
Le le second mode signifie: votre poste de travail peut être indisponible, vous pouvez simplement vous connecter sur un autre a récupérez vos vues (exécutez pour les fichiers privés d'une vue d'instantané)
de Côté la discussion sur 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 créer un environnement simple pour partager rapidement un petit développement entre une petite équipe: pour un petit effort de développement, une vue dynamique peut aider 2 ou 3 développeurs de rester en contact constant avec l'autre, en voyant instantanément lorsque son commit casse quelque chose dans les autres vues.
Pour un effort de développement plus complexe, l ' "isolement" artificiel fourni par la vue instantanée est préférable (vous ne voyez des changements que lorsque vous rafraîchissez - ou "mettre à jour" - votre vue instantanée)
Pour un effort ou un cours de développement réellement divergent, une branche est encore nécessaire pour obtenir un vrai isolement de code (des fusions seront nécessaires à un moment donné, qui ClearCase gère très bien, quoique lentement, fichier par fichier)
Le point est, vous pouvez utiliser les deux, pour les bonnes raisons.
Remarque: par petite équipe je ne veux pas dire "petit projet". ClearCase est le mieux utilisé pour grand , mais si vous voulez utiliser des vues dynamiques, vous devez configurer " branches de tâche 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, partageant rapidement son travail entre ses membres.
Si vous utilisez des vues dynamiques sur une branche "principale" où tout le monde fait quelque chose, alors n'importe quel check-in vous "tuerait" car il pourrait introduire "construire des pauses" sans rapport avec votre effort de développement actuel.
Ce serait alors un mauvais usage des vues dynamiques, et cela oublierait ses autres usages:
- voie supplémentaire de accès aux données , en plus de vues instantanées, ce qui signifie que c'est un excellent outil pour juste "voir" les fichiers (vous pouvez par exemple utiliser une vue dynamique pour modifier sa spécification de configuration jusqu'à ce que vous voyez ce que vous voulez et puis copiez ces règles select dans votre vue snapshot habituelle)
- une vue latérale pour faire des fusions: vous travaillez avec votre vue snapshot, mais pour les fusions vous pouvez utiliser votre" vue Soeur"dynamique ("sister "comme dans" même configuration spec"), afin d'éviter d'avoir une fusion ratée en raison de fichiers cochés (sur lesquels vous travailleriez actuellement sur votre vue snapshot), ou en raison d'une vue snapshot pas complètement à jour. Une fois la fusion terminée, vous mettez à jour votre vue snapshot régulière et de reprendre votre travail.
développer directement en vue dynamique n'est pas toujours la meilleure option car tous les fichiers (non cochés) sont lus sur le réseau .
Cela signifie que la dll, le jar ou l'exe nécessaires à votre IDE seraient accessibles sur 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.
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. Presque toutes les compagnies que je connais qui utilisent ClearCase semblent avoir au moins une personne dont le seul but est de dompter la bête indisciplinée.
le fait même que c'est assez compliqué pour avoir besoin d'une nounou à plein temps est également inquiétant.
Un cauchemar absolu d'un système. cela m'a fait souhaiter que nous puissions retourner à VSS! (peu importe n'importe quel moderne système de contrôle des sources comme Subversion ou Git!)
- c'est slooooow .
- si vous utilisez dynamique vues et le réseau descend vous ne peut pas accéder à votre copie de travail de la source. Vous ne pouvez rien faire mais s'asseoir et d'attendre pour qu'il soit fixe.
- si vous utilisez snapshot vues vous semblez courir dans les conflits et les fichiers "détournés" tout le temps, de sorte que les fichiers dans votre copie de travail sont jamais tout à fait la même que dans le dépôt source .
- chaque fois que vous essayez une grande mise à jour ou de livraison opération it invariablement échoue pour une raison ou une autre, exigeant de votre gourou ClearCase de passer quelques heures/jours à le comprendre. Oh oui, vous doit avoir un gourou de ClearCase dévoué, à plein temps!
- quand il échoue vous souvent ne peut 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 .
- Quand vous regardez passé la jolie(?) icônes, le GUI est très pauvre - jusqu'à des choses comme d'être incapable de redimensionner windows pour voir les chemins complets du fichier!
- leur support le personnel est tout à fait réticent à corriger quoi que ce soit. Leur première réponse est toujours " c'est par la conception " et "pouvez-vous travailler autour d'elle?"S'ils fournissent finalement une solution (après beaucoup d'arguments), ce sera la solution la plus fondamentale possible au problème le plus immédiat.
en gros, c'est lent, complexe et peu fiable comme l'enfer. Oh, et Ai-je mentionné c'est ridiculement cher ? La seule façon de le vendre est de parler à des décideurs qui n'ont jamais utilisé le produit et qui ne le feront jamais! Je suis sûr qu'aucun développeur au monde ne l'achèterait.
Atomic commits and changesets sont mes plus grosses plaintes contre ClearCase. Disons que vous vérifiez cinq fichiers dans le cadre d'une correction de bug ou d'un remaniement. Puis on découvre que quelque chose a foiré et qu'il faut revenir en arrière. Bonne chance pour trouver les cinq fichiers qu'ils sont et quelle version chacun on a besoin d'être sur. Mais prenons un peu de recul. Vous venez de finir d'éditer ces cinq fichiers, et il est temps de s'engager. Les quatre premiers de l'amende. Ce dernier nécessite un massif de fusion. Les quatre autres dossiers sont déjà enregistrés. Ils n'attendent pas que vous finissiez vos changements nécessaires dans le dernier fichier. J'espère que personne n'a mis à jour ou n'utilise une vue dynamique. Un serveur de compilation d'intégration continue va également échouer.
Parfois, nous faisons un tout nouveau répertoire plein de fichiers qui doivent être enregistrés, mais nous ne voulons pas de vérifier eux jusqu'à ce qu'ils sont fait. Il est tôt et tout est encore volatile, alors pourquoi vérifier les choses que vous pouvez supprimer très bientôt? OK, très bien jusqu'à présent. Maintenant, il est temps de vérifier. Vous ajoutez le dossier nouvellement créé au contrôle source. ClearCase n'est pas récursif, donc seulement le dossier single est enregistré. Avec SVN, ce dossier et tout ce qui est en dessous est ajouté, comme vous le souhaitez. Le développeur doit rappeler à tout ajouter, sinon, beaucoup de fichiers vont être manquant.
ClearCase possède les fichiers et dossiers de sorte que vous ne pouvez rien modifier sauf si vous avez vérifié en premier. Le plugin eclipse enlève beaucoup de nuisances ici. Je ne peux pas vous dire combien de fois j'ai ouvert un fichier dans vi pour faire un changement rapide, seulement pour constater que j'avais oublié de vérifier d'abord. La caisse n'est pas récursive.
Les mises à jourpeuvent être douloureusement lentes sans changer les paramètres. Lorsque vous mettez à jour avec une vue d'instantané, chaque mises à jour de fichiers, pas seulement les fichiers modifiés. J'ai travaillé sur un projet avec plus de 20 000 fichiers. Je je me remettais à ma machine de travail, je lançais la mise à jour, puis je me rendais au travail; je prenais le café; je me rendais à mon bureau pendant qu'il finissait de fonctionner. Cela peut sembler exagéré, mais ce n'est malheureusement pas le cas.
vues Dynamiques sont terribles, sauf si vous êtes dans une très petite équipe. Et si c'est le cas, pourquoi avez-vous ClearCase? J'ai vu un nombre incalculable d'opinions se faire étouffer parce que quelqu'un a vérifié dans des fichiers qui ont cassé les vues de tout le monde. Vous devriez toujours mettre à jour et fusionner conflits de votre propre point de vue. De cette façon, les changements ne vous touchent. Avec une vue dynamique, vous ne pouvez pas Fusionner vers le bas avant de repousser vers le haut; vous devez simplement vous engager et espérer.
je sais que le coût n'est probablement pas une grande préoccupation, mais les développeurs qui font l'argent pour la société apprécierait de dépenser les 50k $-100k$(selon la licence ClearQuest, qui est un ajout courant) sur des événements amusants ou de nouveaux équipements (chaises, moniteurs, etc.). IBM recommande d'avoir du personnel pour maintenir ClearCase en marche. Pourquoi ne pas réaffecter ces gens pour générer des revenus pour l'entreprise, au lieu de s'assurer que les choses ne s'écrasent pas?
quelques-unes des raisons que j'ai entendues pour ne pas changer:
- apprendre demande du temps et de l'argent
- apprendre SVN ou Mercurial ne devrait pas prendre plus d'une journée. Seule ClearCase suggère d'avoir un certain ratio d'admins par rapport aux développeurs.
- la Migration sera douloureuse
- C'est pourquoi les outils existent: cc2svn
- ce n'est pas aussi facile avec Mercurial
- sécurité
- il n'y a pas de trous béants dans SVN AFAIK, et L'équipe de développement se consacre à réparer tout ce qui est trouvé rapidement. Le Ministère de la La défense semble D'accord avec SVN.
- pas de gain de productivité réel par la suite
- il faut une éternité pour essayer de traquer les bogues sans modifier les paramètres. J'aime pouvoir reculer jusqu'à ce que je ne puisse pas voir l'insecte. Tu ne peux pas faire ça dans ClearCase.
- Multisite
- WANdisco résout ce problème. Ce n'est pas gratuit.
la seule chose que ClearCase fait mieux que le reste est de brancher des fichiers individuels, tout en gardant les autres sur la même voie qu'une autre branche.
Tout ce que j'ai fait dans Clearcase semble toujours dur . Cependant, 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.
mon expérience avec ClearCase a été un désastre, et je vais appuyer la déclaration de Don que cela nécessite un expert résident -- malheureusement nous avons eu plus d'un. J'avais de l'expérience avec le 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 reprises; différents experts m'ont donné des conseils contradictoires au point où nous avons en fait cassé le cd . C'est après que j'ai émis un 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 devrait suffire, en utilisant un schéma de fichier qui joue bien avec les autres. Pour moi ClearCase ressemble au résultat d'un marketing exec délibérément compliquer l'enfer des choses pour faire paraître le produit sophistiqué et puissant. J'ai entendu dire qu'il peut être configuré pour se comporter dans un simple, sûr, fiable, mais encore une fois cela nécessite les services d'un expert-hors de la boîte c'est comme un couteau de l'armée suisse motorisé.
Tout j'ai vécu lié en aucune capacité à ClearCase est inefficace, laid, trop complexe, trop lent, confusion, coûteuse et peu pratique.
il semble attirer les gestionnaires et les ingénieurs qui ont tout faux.
Merde, IBM et Rational doivent avoir des vendeurs incroyables pour vendre un produit aussi merdique.
nous sommes en train de migrer de CC vers Git pour plusieurs des raisons indiquées ici. Je voudrais ajouter une raison de rester à l'écart de CC ou de tout autre système de contrôle des sources commerciales.
vos données commerciales vitales sont l'otage de ClearCase. Vous ne pouvez pas le sortir.
vos données commerciales vitales sont le code, son historique de version et toutes les métadonnées telles que les commentaires de commit, qui s'est enregistré et quand.
Tous les logiciels peu durée de vie utile. Vous devriez toujours vous demander quand vous introduisez un nouveau système qui avale les données importantes de l'entreprise, si c'est le code, les bogues, les données de client ou quoi pas: comment puis-je obtenir mes données à nouveau? Si vous ne pouvez pas répondre à cette question, vous ne devriez pas introduire ce système.
lorsque nous avons migré, nous avons perdu la plus grande partie de notre histoire et toutes nos métadonnées. Essentiellement, nous avons seulement l'histoire correspondant aux versions publiées, mais l'information sur ce que les changements ont été faits dans réponse à ce que le client demande est perdu (nous avons ces données dans le support client et le système de ticket de bug, donc il n'est pas complètement perdu, mais le couplage au code source est parti).
ce sera quelque part entre une nuisance et un problème pour nous à court et moyen terme. Dans quelques années, ce n'est plus important, mais peut-être pendant 1 à 3 ans, ce sera important.
(il existe des outils commerciaux pour migrer les PC vers d'autres MCs, mais ils ne sont pas et je doute que cela eût été faisable. L'exportation minimale que nous avons faite a pris assez de temps.)
la leçon à tirer est la suivante: Ne jamais confier de données commerciales vitales à des systèmes propriétaires.
Non atomique s'engage
une fois que vous avez vérifié dans les fichiers, il est très difficile de revenir à un certain état, parce que les propagations atomiques ne sont pas supportées. Lors de la vérification de plusieurs fichiers, chaque fichier reçoit une nouvelle révision (similaire à CVS) et non le check-in lui-même. Je pense que c'est une fonctionnalité cruciale, parce que vous ne voulez pas revert des fichiers uniques mais des actions de propagation complètes (qui devraient cartographier les tâches). Avec ClearCase vous ne pouvez revenir à certains états par en utilisant des étiquettes. Dans la pratique, L'utilisation d'étiquettes ClearCase pour chaque check-in est excessive et n'est donc pas faite.
de Merde de l'interface utilisateur
L'interface graphique de ClearCase Explorer n'est qu'une blague. Horrible dans la facilité d'utilisation et l'apparence laide. Des fonctions différentes et souvent nécessaires ne sont pas fournies (par exemple, vérification récursive des artefacts travaillés). Outil en ligne de commande cleartool utilisé avec cygwin est beaucoup mieux, mais certaines choses ne sont pas encore disponibles comme ajouter récursivement de nouveaux fichiers/dossiers au contrôle source. Je dois me marrer si je lis un script de 50 lignes de code pour contourner ça.
la Haute administration efforts
administrer ClearCase beast est loin d'être évident ou léger (à la différence des autres systèmes scm comme CVS, subversion ou Git). Attendez-vous à mettre un certain nombre d'experts de cas de ClearCase dédié pour juste le maintenir en fonctionnement.
Horrible performance
rien n'est pire que de faire attendre vos développeurs en interfaçant avec SCM-tool, c'est comme conduire avec des freins à main activés. Il ralentit votre cerveau et de votre travail. Obtenir de nouveaux fichiers frais à votre vue d'instantané prend environ 30 minutes pour les artéfacts 10K. Une mise à jour (aucun artefact n'a été modifié) pour la même quantité prend environ 5 minutes. Lorsque vous expérimentez beaucoup et sautez entre différentes vues à jour signifie beaucoup d'attente. C'est encore pire, lorsque vous travaillez sur des fichiers et que vous voulez vérifier ou mettre à jour. Le Check-out, le check-in et l'ajout aux cycles de contrôle source prennent environ 10-15 secondes ce qui est évidemment un cauchemar. Cela devient très gênant lorsque vous renommez/déplacez des types ou des méthodes (de nombreux fichiers peuvent être affectés).
manque de soutien au développement distribué
aujourd'hui, le développement de logiciels est souvent chose distribuée (les développeurs sont répartis dans le monde entier travaillant sur le même produit/projet). ClearCase n'est certainement pas adapté pour cela, car il est mal adapté pour le travail hors ligne. Faire une check-out (action avant de pouvoir éditer un fichier/dossier) nécessite que vous soyez 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 d'arrivée/départ peut même augmenter de façon si spectaculaire qu'elle n'est pas utilisable du tout. Il y a des solutions de rechange pour cela comme l'utilisation de ClearCase Multisite (scm DB replica technologie), 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 de bons logiciels. Mais en regardant IBM-monster ClearCase Je ne le ferais pas investir mon argent ici, il a tous ces défauts discutés, et plus IBM ne semble pas investir de l'argent pour améliorer leur produit de manière significative. Récemment, j'ai eu un look un git scm qui semble très bon, surtout pour ses caractéristiques branching+merging, où ClearCase a ses principaux points forts.
cette information est tirée de http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase /
probablement le pire logiciel jamais fait. Je ne travaillerai pour aucune entreprise qui utilise quelque chose de rationnel. Mis à part CC complètement s'écraser et redémarrer mon poste de travail fréquemment sur les constructions dynamiques. Que se passe-t-il lorsque vous poussez quelque chose au contrôle source et que CC fait ce qu'il fait le mieux, crash? Votre code est-il alors mis dans lost+found, sauvegardé quelque part peut-être? Non, il est parti pour toujours. Donc, si vous êtes un jour dans la situation de Dieu-terrible de l'utilisation de ce morceau géant de logiciel coûteux, garder une copie de tout ce. Bon travail rationnel / IBM. Façon de saisir la partie la plus importante du contrôle à la source, la fiabilité. Die slow.
Downsides de ClearCase-un ajout au post le plus en profondeur ici.
-
l'outil de fusion n'en vaut pas la peine. Il vous aide à peine, se souvient pas de décisions que vous avez prises, c'est juste une diff glorifiée.
-
l'outil de fusion doit vérifier les répertoires pour même vérifier s'ils ont besoin d'une fusion. Il est un peu fou.
-
J'utilise BitKeeper au travail (supposons Git), et fusionner deux dépôts même s'il y a des conflits est tellement trivial et convivial même avec la ligne de commande, tandis que ClearCase ayant des tonnes d'outils GUI est un processus long et laborieux qui est aussi extrêmement sujet à des erreurs.
-
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 à haute vitesse. Ainsi, un clic droit dans L'outil ClearCase sur un fichier travaillant à partir de la maison pourrait prendre une minute ou deux à avoir des vitesse internet en raison de l'extrême quantité d'exigences de réseau.
-
Quelqu'un peut complètement gâcher le dépôt ou les check-in s'ils font leur spécification de vue différente de l'équipe. Ce qui est tout à fait fou que personne ne peut simplement vérifier une branche; ils ont besoin de la spécification de vue appropriée qui leur donnera d'ailleurs la bonne chose. L'ensemble du concept peut être agréable et flexible, mais 99% du temps, il provoque juste beaucoup de douleur. Ai-je mentionné vous ne pouvez pas envoyer vos spécifications via Microsoft Outlook car les outils CC n'acceptent pas UTF-8 et vous ne pouvez donc pas les copier-coller?
-
je n'ai absolument rien de gentil à 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, me sentant heureuse tout le temps. Il est également impossible de simplement expérimenter à la maison avec vos propres projets, de sorte que vous apprendrez encore SVN ou Git à la maison, et être forcé de passer par ClearCase douleurs au travail. Personne que je connaisse n'a jamais utilisé CC volontairement. Ils ne l'utilisent que parce qu'un directeur au travail a décidé que CC est la voie du salut et a forcé tout le monde à migrer vers elle. En fait, ma dernière entreprise a migré de CVS à ClearCase, et après un an de ClearCase à SVN. C'est que détesté.
-
ClearCase n'est pas juste une chose qui vous fait dire non. C'est comme vivre dans une maison infestée de fourmis. Chaque fourmi est au mieux un petit inconvénient., mais l'infestation de fou.
j'essaie de regrouper quelques commentaires dans un vrai post ici. Je ne suis pas vraiment ici pour vous convaincre que l'un est meilleur que l'autre, sauf pour faire quelques remarques:
- si vous comparez git et ClearCase, je soumets respectueusement que vous avez besoin de mieux définir vos besoins - si vous envisagez ClearCase pour une "bonne" raison, le git n'est probablement même pas dans l'équation - il est beaucoup trop nouveau à faire confiance pour le contrôle des sources au niveau de l'entreprise, OMI.
- ClearCase introduit beaucoup de concepts dans l'espace de contrôle de version que les autres systèmes n'ont pas, donc il 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 bases de code énormes pris en charge par des développeurs qui ne sont pas sur un LAN avec un serveur VOB. Vous pouvez avoir plusieurs répliques (multi-site) 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 une version de fichier ou une version de dépôt? Il s'agit d'une question assez importante, qui filtrera nécessairement tout un ensemble d'outils, ce qui facilitera votre travail. Le versioning du dépôt a beaucoup d'avantages (et il n'est pas "nouveau", comme certains posters l'ont prétendu - les outils commerciaux comme Perforce ont été autour pour plus une douzaine d'années, et il peut y avoir des outils qui ne référentiel de gestion des versions, même avant de Perforce), mais ce n'est pas une panacée.
- avec une installation suffisamment grande de n'importe quel système de contrôle source, vous allez avoir besoin d'aide. Lorsque vous envisagez d'utiliser des outils, vous devez tenir compte de la facilité avec laquelle il sera possible de trouver des personnes pour vous aider (soit des candidats qui ont de l'expérience, soit des consultants qui seront présents à un moment donné pour vous aider à régler les problèmes). Il n'y a pas une telle chose comme un système SCM sans entretien, et en supposant que vous avez un vous mettra dans plus de problèmes que de choisir un qui nécessite" trop " d'administration.
- ne prêtez pas trop d'attention aux gens qui disent à quel point les" vues dynamiques " sont mauvaises - les mauvaises politiques de GCA sont mauvaises, peu importe l'outil que vous utilisez. Vos politiques et pratiques de gestion de la configuration doivent être séparées de votre choix d'outil - aucun outil n'empêchera les gens de briser toute votre base de données si vous ne le faites pas définir des politiques de ramification et de fusion sensées. Si quelqu'un suggère que le fait que les développeurs s'engagent directement sur /main est une idée raisonnable, vous pourriez vouloir vous éloigner de cette conversation.
ClearCase est un bel outil, mais il est un compliqué de l'outil. Il n'y a aucun moyen de contourner cela - il n'a pas un 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, puisque les projets Open Source ont tendance à juste inventer une nouvelle taxonomie là où il en existait déjà une), mais certaines choses sont certainement plus faciles/plus difficiles pour un système donné, selon leur conception. Les vues "snapshot" de ClearCase sont essentiellement la même chose que vous auriez si vous aviez vérifié un dépôt à partir de SVN ou CVS - c'est une copie locale du code source sur votre machine, avec des pointeurs vers le serveur central pour que les outils puissent interroger l'historique des versions, etc. Vous peut fonctionner avec ces vues sans aucune connexion réseau vers le serveur ClearCase une fois qu'elles ont été créées, et vous pouvez les "recycler" pour éviter de télécharger à nouveau l'ensemble de votre dépôt lorsque vous souhaitez travailler sur une autre branche, par exemple. Les "vues dynamiques" sont essentiellement une invention ClearCase, et le mode de fonctionnement standard d'un LAN. Ils apparaissent de la même façon que la vérification D'un dépôt SVN, mais ils ne copient aucun fichier avant que vous ne fassiez des changements. De cette façon, la vue est disponible immédiatement, mais il est évident qu'il ne peut pas être utilisé si le serveur clearcase principal n'est pas disponible, et qu'il est désagréable de travailler avec une connexion à haute latence. Ils ont également la commodité de pouvoir être monté comme un lecteur réseau sur n'importe quelle machine avec accès au serveur sur lequel ils ont été créés, donc si votre poste de travail windows meurt, vous pouvez simplement vous connecter sur un autre, monter votre vue, et de revenir au travail, puisque tous les fichiers sont stockés soit dans le serveur VOB (pour les fichiers vous n'avez pas modifié sur cette branche), ou le view_server (pour les fichiers que vous avez créés ou modifiés juste dans cette vue).
aussi, et cela mérite son propre paragraphe....clearmerge vaut presque le prix d'entrée seul. C'est le meilleur outil de fusion que j'ai utilisé dans ma vie. Je crois fermement que beaucoup de mauvaises pratiques dans SCM ont été développées en raison d'un manque d'outils de fusion de haute qualité, donc les utilisateurs CVS n'ont jamais appris à utiliser les branches correctement et cette crainte de la ramification s'est propagée jusqu'à nos jours sans raison particulière.
Ok, tout cela étant dit, si vous cherchez des raisons de ne pas utiliser ClearCase, elles ne sont pas difficiles à trouver, bien que je pense que c'est la mauvaise façon de procéder. Vraiment, vous devriez avoir besoin de trouver de bonnes raisons d'utiliser ClearCase, pas des raisons de ne pas utiliser ClearCase. Vous devriez venir dans n'importe quelle situation SCM en supposant que ClearCase est trop outil ou trop compliqué un outil pour le travail, et puis voir si vous avez une situation qui vous encourage à l'utiliser de toute façon. Avoir IBM ou logos rationnels n'est pas une bonne raison.. :- )
Je ne considérerais même pas ClearCase à moins que vous puissiez dire oui à tous les énoncés suivants:
- vous faites maintenant, ou aurez éventuellement, plus de 50 développeurs travaillant sur la même base de code.
- la plupart de ces développeurs sont centralisés, ou ont un haut débit faible latence connexion à un emplacement central.
- vous avez un ensemble de politiques SCM et pouvez identifier comment utiliser ClearCase pour appliquer ces politiques (vraiment vous devriez considérer ceci pour n'importe quel outil)
- le fait que l'Argent n'est pas un objet
mon expérience est principalement limitée par CC, CVS et SVN. En principe, CC est technologiquement capable, prêt à l'entreprise et comparable par des caractéristiques avec n'importe quel VCS moderne. Mais il a plusieurs défauts qui le rendent inutilisable dans toute orientée vers l'environnement. Pour les environnements orientés processus, c'est probablement plus approprié, bien que je doute que de tels environnements soient appropriés par eux-mêmes. Peut-être, dans les logiciels militaires, cosmiques ou médicaux, Je ne sais pas. De toute façon, je crois que, même pour ces domaines il existe des outils appropriés et encore plus conviviaux.
en plus D'être un VCS techniquement capable, CC possède plusieurs avantages distinctifs:
- vues dynamiques
- bel arbre de version
- Déclencheurs
- Bonne fusion de versions, y compris renomme
à mon avis, leur utilisation est limitée sauf la dernière; et ils ne compensent pas les défauts. Vue dynamique agréable en théorie, mais pas toujours disponible en pratique. Version tree est beaucoup moins utilisé dans les autres VCS, alors qu'il est nécessaire en CC en raison de la prolifération des branches (voir 6). Déclencheurs, comme je le sais, très détaillé et capable, mais je pense que pour la plupart des tâches pratiques SVN hooks sont assez bons. Et maintenant sur les inconvénients qui concernent principalement la convivialité:
- CC échoue totalement dans le sens de l'utilisabilité pour le groupe d'utilisateurs principal: pour les développeurs. Et c'est le principal raison pour laquelle je pense qu'il ne devrait jamais être utilisé dans un environnement, que ce soit une entreprise ou non. Même s'il était gratuit, il sucerait néanmoins l'argent de votre entreprise en gaspillant le temps de vos développeurs et les frustrer. Ce point est composé de:
- "découvrez-le Check-In" avec la plus stricte de verrouillage approche - c'est contre-productif, refactoring hostile et dangereux dans le dépôt des organisations avec une seule branche de développement pour de nombreux développeurs. Pendant ce temps, l' avantages de la stricte verrouillage sont négligeables.
- mauvais rendement et haute charge
- il ne peut effectivement pas être utilisé à distance sans multi-site (en raison de 2). Multisite est cher aussi. ClearCase client distant est très limité. Il n'a même pas
cleartool
(avant la version 7.1), laissant de côté les vues dynamiques. - il peut difficilement être utilisé hors ligne. Les vues dynamiques ne fonctionnent pas. Les vues instantanées sont effectivement lues uniquement, parce que vous ne peut pas sortir sans accès au dépôt (voir 1). Hijack est une mauvaise option qui signifie en fait que CC renonce à toute responsabilité pour le fichier piraté. Et CC ne peut pas vous montrer la différence avec la révision précédente quand offline. SVN est capable de montrer la différence avec la révision précédente, même hors ligne.
- modèle trop compliqué, en particulier avec UCM: VOBs, PVOBs, projets, flux, branches, vues, deliver, update, load, restore, rebase, merge, baseline, check in, check out. Je pensez 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 trucs de base sur le CC.
- prolifération de branches. Par exemple, le dépôt est souvent organisé en flux par développeur (en raison de 1). Il n'a tout simplement aucun sens dans SVN ou la plupart des autres VCSs.
- aucune révision à l'échelle du dépôt. Eh bien, il y a des révisions comme comprendre, ils ont appelé les bases. Mais quand je vois une révision de fichier et que je veux obtenir un instantané du dépôt au moment de cette révision de fichier, je vais avoir quelques problèmes. Je vais avoir besoin de faire de la magie noire avec des spécifications de configuration pour créer une vue instantanée, ou trouver d'une façon ou d'une autre à travers la vue dynamique si elle est disponible.
- Version tree, même si elle est agréable, a une facilité d'utilisation médiocre. L'outil de fusion est juste dommage. Autres "caractéristiques": fenêtres non redimensionnables, absence de recherche incrémentale dans certains endroits, interface centrée sur la souris, look and feel dans le style de 1995, flux de travail étrange distribué entre Client et Project Explorer etc.
- CC provoque rares et de vastes check in. Vous savez tous que le check-in doit être petit et fréquent. Mais les développeurs s'abstiennent généralement d'interactions supplémentaires avec CC, les fichiers hijack et de travailler dans les VCS locaux ou même sans VCS du tout (ce qui est plus souvent, malheureusement). Et puis, après deux semaines de développement qu'ils commencent à s'engager comlex fonctionnalité ajoute 20 fichiers et affecte 20 autres fichiers. Il dure un jour ou deux, parce qu'ils ont détourné des fichiers et ont maintenant besoin d'effectuer une fusion manuelle avec toutes les nouvelles modifications de repo et de résoudre tous les conflits et les anomalies. Pendant ce processus, le code n'est pas compilable, car plusieurs fichiers ont été enregistrés avec succès et d'autres non. Et après cela, il n'est toujours pas compilable parce qu'ils ont oublié d'ajouter 2 autres fichiers au CC.
- c'est très cher
- c'est très complexe en termes d'infrastructure et nécessite des administrateurs dédiés
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 la convivialité de Visual Source Safe. Et chaque fois que vous voulez faire quelque chose d'un peu plus compliqué que vos scripts permettent, vous obtenez un sentiment de malaise dans votre estomac.
comparez ceci avec Git, ce qui semble compliqué de l'extérieur, mais après une semaine de travail avec elle, vous vous sentez complètement en contrôle. Le référentiel modèle est simple à comprendre, et incroyablement puissant. Parce qu'il est facile d'obtenir les écrous et les 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 telle que comment juste voir une version non-HEAD d'un fichier dans une vue d'instantané m'a pris quelques heures et ce que j'ai fini avec était un hack complet . Pas agréable sorte de hack.
mais dans Git, trouver une tâche apparemment compliquée telle que 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 étant un accident de la façon dont nous avons utilisé le VCS. "Git signifie ne jamais avoir à dire "vous devez avoir "" .
à mon travail, J'utilise Git pour toutes sortes de tâches légères, même dans ClearCase. Par exemple, je fais de la TDD, et je m'engage à passer toutes les fois qu'un tas de tests passent et que je suis sur le point de me reformuler. Quand la tâche est finalement terminée, je vérifie à ClearCase, et Git m'aide à passer en revue exactement ce que je change. Il suffit d'essayer D'obtenir ClearCase pour produire une diff à travers quelques fichiers - il ne peut pas! Utilisez Google pour découvrir les différents hacks personnes ont essayé de travail autour de cela. C'est quelque chose que le contrôle de version devrait faire hors de la boîte, et ça devrait être facile! CVS a cela depuis des décennies!
- Cauchemar à administrer dans des environnements sécurisés
- technologie dépassée
- GUI Non intuitif
- cher
- monstre des ressources
- vente à la découpe de Microsoft
à mon avis? Seule raison d'en avoir? Si vous suivez religieusement le RUP.
le soutien est terrible. On a des billets ouverts depuis des années. Notre gourou eclipse a en fait corrigé un bug dans leur plugin eclipse localement en environ 30 minutes en démontant le fichier java. Mais le billet n'a pas encore dépassé le niveau 1 de soutien. De temps en temps, ils essayent soit de la fermer en douce, soit de nous la renvoyer "pour essayer la dernière version" (même si nous leur envoyons une recette de reproduction qu'ils peuvent essayer eux-mêmes.).
ne pas toucher à une barge pôle.
Performance.
ClearCase est puissant, stable (si bien entretenu et supervisé) mais il est lent. Géologique parfois.
vues dynamiques les vues conduisent à des temps de construction horribles, les vues instantanées peuvent prendre des âges à mettre à jour (pause déjeuner pour les grands projets) ou à vérifier (rentrer à la maison pour la journée).
Clearcase est si ennuyeux qu'il pousse en fait les gens à écrire de la poésie à son sujet:
http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html
http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it /
-
" les développeurs vont passer la moitié de leur temps à comprendre clearcase avant de faire n'importe quel travail et une fois qu'ils l'ont compris ils installeront git localement et pousseront seulement au repo clearcase si nécessaire.
-
vous devrez employer un administrateur de Clearcase dédié.
je suggère SVN pour toolset et Git pour scaling/workflow. Je suggère aussi d'éviter le CC quand c'est possible. (Sans compter l'argent, le fait qu'il est une telle douleur à utiliser qui est nécessite un administrateur à temps plein est une blague totale)
j'ai dû récemment me disputer avec une situation similaire. Peut-être que tu peux apprendre de mon histoire.
l'équipe à laquelle je venais d'être affectée utilisait un outil lourd de façon alambiquée et sujette aux erreurs. J'ai d'abord essayé de les vendre sur mes outils et processus de choix. Cette tentative échoua lamentablement. J'ai été sidéré qu'ils choisiraient un environnement aussi accablant plutôt qu'un environnement à la fois plus facile et plus efficace. S'avère qu'ils ont voulu être discipliné, et à l'aide d'un processus douloureux ressenti disciplinée. Ça sonne bizarre, mais c'est vrai. Ils avaient beaucoup d'autres idées fausses trop. Après que j'ai compris ce qu'ils étaient après, nous avons en fait collé avec la même suite d'outils (Serena), mais a changé massivement la façon dont il a été configuré.
je vous conseille de trouver ce qui compte pour votre équipe. Voler ClearCase ne vous mènera nulle part si vous ne parlez pas à leurs intérêts. Aussi, découvrez pourquoi ils ne veulent pas utiliser alternative. Essentiellement faire un petit rassemblement des exigences et adapter vos choix d'outils à vos besoins. Selon vos choix, qui sait, l'Affaire peut être la meilleure option après tout.
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 facilement travailler à la maison, parce que je n'ai pas accès au serveur de licence. Même avec une vue instantanée sur mon ordinateur portable je dois jouer des tours parce que je ne peux pas obtenir une licence. Il existe un client distant spécial, mais ajoute des tonnes de ses propres limites au mix
- limitations de licence encore une fois-seulement ainsi il y a beaucoup de sièges à contourner, et personne ne peut s'en servir.
- outils Unix obsolètes - ClearCase semble fonctionner le mieux sur les systèmes Unix, mais les outils GUI sont nuls. L'intégration Windows / Unix de ClearCase introduit toutes sortes de douleurs.
la plus grande chute pour moi est à la fois la performance (surtout si votre VOB est multisite ou hors site), et potentiellement de longues périodes d'arrêt.
si vous êtes comme moi et que vous travaillez dans un bureau relativement petit dans le cadre d'une grande entreprise (sans L'avoir sur place), les serveurs Clearcase qui tombent peuvent vous coûter la plus grande partie d'une journée de travail en non-productivité ainsi que d'obtenir les bonnes personnes pour le faire réparer.
ligne de fond, utilisez-le SEULEMENT si vous avez vraiment besoin pour ce que vous faites et assurez-vous d'avoir un costaud C'budget pour l'entretenir.
ClearCase est parfaitement utilisable si vous êtes prêt à utiliser un autre système de contrôle de version en plus! personnellement, je trouve que l'utilisation mercurial ontop de CC fonctionne assez bien.
- non atomique archivages
à partir de la nouvelle version de la version 7.1 CC fournit la vérification atomique comme fonctionnalité si vous aimez cela. Personnellement, je ne le voudrais vraiment pas, mais apparemment certaines personnes voient cela comme "une caractéristique essentielle". Je ne voudrais pas d'un gros paquet en une seule fois comme une sorte de version massive. Puis de nouveau... si vous voulez qu'il vient de l'allumer.
so... n'est plus un argument.
nous avons utilisé UCM ClearCase intégré à ClearQuest (DR Tracking/change request system) pour les 4 dernières années avec plus de 50 développeurs. Nous avons plus de 50 projets UCM plus de milliers de flux qui ont traité plus de 35K DRs et demandes de changement. Au cours de cette période, Nous avons officiellement effectué plus de 600 livraisons d'intégration, tout en déployant jusqu'à six efforts de développement et de diffusion simultanés.
je suis le type principal CM / ClearCase avec une sauvegarde qui est capable d'effectuer le livraison régulière / Fusion et construction de l'intégration. 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 du côté des MC dans cet énorme effort de développement et que nous n'avons jamais été un échec du spectacle. Nos développeurs ont été formés avec juste le matériel de base et un simple pas leur a été donné chaque fois qu'un nouveau projet (branche) a été créé à la demande de la direction du projet.
trop de développeurs se sont plaints de ClearCase parce qu'ils n'ont pas le bon soutien CM/IT/ClearCase/Process/Management. Les développeurs devraient se concentrer sur le développement et non sur la GCA OU être un spécialiste des outils. Pour un développement logiciel important, au moins 5 à 7% du budget devrait être consacré à la GC et au soutien des outils.
exécute un JDK à partir d'un VOB sous Linux.
essayez, vous devez jouer avec la variable LD_PRELOAD (je sais!)
le point de "on a besoin d'une personne dédiée" et "c'est compliqué", etc....
le problème principal ici en trouvant cela un problème est que vous devez définir si vous voulez avoir la gestion de configuration effectuée dans votre organisation (qui N'est pas la gestion de version). La gestion de la Configuration est comme la gestion de projet: même sans un outil, vous pouvez toujours faire la gestion de projet et sans un outil, vous pouvez faire la gestion de Configuration. Beaucoup de gens ont un moment difficile comprendre cela et beaucoup de gens pensent que la gestion de Configuration est égale à un outil qui versions des sources de logiciels ou quelque chose...... (donc des comparaisons avec des subversions ou d'autres systèmes de gestion de versions)
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").
So... si, à votre avis, cette personne dévouée est là pour gérer un outil je pense qu'il ya quelque chose de très mal. À mon avis, il y a une personne dévouée qui s'occupe de la gestion de la configuration et qui, du point de vue de l'utilisateur final, ne se présente que lorsqu'il y a un problème avec l'outil, mais considère que ce n'est que 1% de son travail.
alors ce que vous devez faire (comme dans tout autre projet de logiciel), retournez à vos exigences et dressez une liste d'exigences sur ce que votre organisation veut avec la gestion de la configuration. Et oui comme dans tout autre projet de logiciel, vous aurez des utilisateurs (comme les développeurs) qui ne sont pas totalement d'accord avec les autres utilisateurs (comme la gestion) sur certaines exigences. Il y a la clé imho sur certaines réactions que j'ai lues ici.
et IMHO si vous avez la liste des exigences de l'organisation et un gestionnaire de configuration dans le mix.... le choix est assez clair (voir aussi le forum sur www.cmcrossroads.com)
ClearCase n'est pas seulement un outil 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 évolué.
et... Je pense que le choix d'un système de gestion de projet ne devrait jamais incomber à des développeurs égaux au choix du bon outil de gestion de projet ou du bon système de gestion de la relation client. Les développeurs sont les utilisateurs finaux d'une certaine partie de la fonctionnalité de l'outil.
je serai peut-être seul ici, mais ClearCase n'est pas si mal que tout le monde le dit. Il peut prendre en charge énorme repositeories. Vue dynamique sont assez cool et puissante caractéristique aussi. Il est fiable, peut être personnalisé en ajoutant des déclencheurs et des contraintes sur une base de fichier EEP, permissions, etc.
malheureusement, il est livré avec un prix, Grand Prix. Il est coûteux, et pour fonctionner correctement, doit être correctement configuré et maintenu par une équipe dédiée. Cela le rend vraiment bon pour BigCo, mais pas un choix si sage pour SmallFirm.
je suis un grand fan de DVCS et git, mais je peux comprendre pourquoi BigCo choisirait ClearCase plutôt que SVN et git. Ce que je ne peux pas comprendre pourquoi quelqu'un choisirait SVN plutôt que Git; >
Vues Dynamiques. Doit admirer un système de fichiers translucide entièrement fonctionnel.
un grand avantage est que la propriété intellectuelle est toujours dans le réseau de l'entreprise. Un ordinateur portable peut être perdu / volé et aucun code source en danger.
un autre est l'accès instantané au code source et aux fichiers modifiés, aucun temps n'est jamais passé à télécharger quoi que ce soit.
Il sert bien pour le but qu'il possède.