65 votes

Quels sont les concepts de base de ClearCase que chaque développeur devrait connaître ?

Quels sont les concepts principaux du système de contrôle de version Clearcase que chaque développeur devrait connaître?

2 votes

À tout modérateur, s'il vous plaît ne supprimez pas cette question (s'il vous plaît). Je comprends que cela ne correspond pas aux normes actuelles de SO, mais cela représente 12 années d'expérience sur cet outil (ClearCase) et devrait apporter une valeur ajoutée durable pour les pauvres âmes coincées avec ce système de contrôle de version.

4voto

Matt Curtis Points 12454

Comment utiliser git sur le dessus de ClearCase!

2voto

paxdiablo Points 341644

À mon avis, le branchement et la fusion sont les concepts les plus importants dans tout système de contrôle de source (à côté du versionnage lui-même, bien sûr).

Une fois que vous comprenez comment c'est fait (et Clearcase le fait très bien, au point où nous faisons même de petits changements en tant que branche et re-mergeons, ce que je n'aurais jamais fait avec RCS ou CVS), vous trouverez que votre vie est beaucoup plus facile.

2voto

siddhadev Points 6083

Quelque peu hors sujet, mais - je ne connais presque aucun développeur satisfait de ClearCase. On m'a dit qu'il devrait avoir des fonctionnalités sophistiquées, mais en tant qu'utilisateur de svn et git, je ne peux pas penser à quelque chose qui me manque dans git ou subversion. C'est donc quelque chose que l'on devrait savoir sur ClearCase - la plupart des développeurs sont vraiment contents de travailler avec quelque chose d'aussi simple que subversion ou git (oui, même git est plus facile à comprendre), Et même après avoir appris comment accomplir les tâches les plus simples dans ClearCase, j'avais constamment le sentiment que ClearCase travaille contre moi, pas avec moi.

1voto

Decio Points 41

J'ai travaillé avec succès sur un certain nombre de projets de taille moyenne à grande en utilisant à la fois Clearcase et SVN. Les deux sont d'excellents outils mais l'équipe qui les utilise a besoin de processus documentés. Créez un processus qui décrit comment vous utiliserez le système de contrôle de version.

1) Trouvez ou créez un document sur les meilleures pratiques pour votre système de contrôle de version. En voici un pour subversion, adaptez-le à votre processus Clearcase. Tous les développeurs doivent adhérer au même plan de jeu.

Décidez essentiellement si vous allez 'toujours brancher' ou 'ne jamais brancher'.

Schéma Sans Branchement :

  • Le schéma sans branchement est ce que SourceSafe utilise où les fichiers sont verrouillés pendant le checkout et deviennent disponibles lors du checkin. Ce schéma est correct pour les petits projets d'équipe (1 ou 2 développeurs).

Schéma Toujours Branché :

  • Le schéma toujours branché signifie que les développeurs créent des branches pour chaque correction de bogue ou ajout de fonctionnalité. Ce schéma est nécessaire pour les projets plus importants, les projets ayant un responsable (buildmeister) qui gère les changements autorisés dans /main/LATEST dans Clearcase ou /trunk dans SVN.
  • Le schéma toujours branché signifie que vous pouvez effectuer des checkins fréquents sans craindre de casser la construction. Votre seule opportunité de casser la construction est uniquement après que votre correction de bogue ou fonctionnalité soit complète et que vous la fusionnez dans /main/LATEST.

'Brancher lorsque nécessaire' est un compromis et peut fonctionner le mieux pour de nombreux projets.

2) Avec Clearcase (et Subversion), vous devez apprendre à fusionner - la fusion est votre amie. Apprenez à utiliser les capacités de fusion de ClearCase ou utilisez un outil comme Beyond Compare ou emacs-diff. Si votre projet est bien modularisé (de nombreux petits fichiers découplés), vous bénéficierez de moins (ou pas du tout) de conflits lors de la fusion.

3) Profitez-en.

1voto

Englebart Points 11

Si vous utilisez ClearCase, assurez-vous d'utiliser le UCM qui l'accompagne et les composants composites.

Cela rend tous vos branches/fusions sans effort. Je parle de restructurations majeures des branches qui durent 6 mois impliquant des dizaines de milliers de modifications incluant le renommage de répertoires, le renommage de fichiers, etc. qui résolvent automatiquement 99,9% des deltas.

De plus, nous n'utilisons que des vues Snapshot, pas des vues dynamiques. Nos vues snapshot se chargent plus rapidement que vous ne pouvez faire glisser et déposer (Windows) le même arbre source depuis un lecteur réseau.

Le seul reproche que j'ai concernant UCM est que l'historique ne peut pas s'étendre sur plusieurs composants. Si vous divisez un composant en plusieurs nouveaux composants, chaque nouveau composant démarre à /main/0.

1 votes

Je fais souvent des livraisons/remises en utilisant une vue dynamique, car les fusions y sont bien plus rapides et ne sont pas bloquées en raison d'une vue instantanée non entièrement mise à jour. Ensuite, je mets à jour ma vue instantanée avec le résultat de ladite fusion et je continue de travailler.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X