65 votes

Quels sont les concepts de base de Clearcase que tout développeur devrait connaître ?

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

2 votes

A tout modérateur, Ne supprimez pas cette question, s'il vous plaît (s'il te plaît). Je comprends que cela ne corresponde pas aux normes actuelles de l'OS, mais cela représente 12 ans d'expérience sur cet outil (ClearCase) et devrait apporter une valeur ajoutée durable aux pauvres âmes coincées avec ce VCS.

4voto

Matt Curtis Points 12454

Comment utiliser git en plus de ClearCase !

2voto

paxdiablo Points 341644

À mon avis, le branchement et la fusion sont les concepts les plus importants de tout système de contrôle des sources (après le versionnement lui-même, bien sûr).

Une fois que vous avez compris comment cela se fait (et Clearcase le fait très bien, au point que nous faisons même de petits changements sous forme de branche et de re-fusion, ce que je n'aurais jamais fait avec RCS ou CVS), vous trouverez que votre vie est beaucoup plus facile.

2voto

siddhadev Points 6083

Un peu hors sujet, mais - je ne connais pratiquement aucun développeur qui soit 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 qu'il faut savoir à propos de ClearCase - la plupart des développeurs sont vraiment heureux de travailler avec quelque chose de simple comme subversion ou git (oui, même git est plus facile à appréhender), et même après avoir appris à accomplir les tâches les plus simples dans ClearCase, j'ai eu le sentiment constant que ClearCase travaille contre moi, pas avec moi.

1voto

Decio Points 41

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

1) trouver ou créer un document sur les meilleures pratiques pour votre système de contrôle des versions. En voici un pour la subversion et l'adapter à votre processus Clearcase. Tous les développeurs doivent adhérer au même plan de match.

En gros, décidez si vous allez "toujours bifurquer" ou "jamais bifurquer".

Jamais de schéma de branchement :

  • Le schéma "never branch" est celui utilisé par SourceSafe, où les fichiers sont verrouillés lors de l'extraction et deviennent disponibles lors de l'archivage. Ce schéma convient aux petits projets d'équipe (1 ou 2 développeurs).

Toujours le schéma de la branche :

  • Le schéma "always 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 grands projets, les projets qui ont un responsable (buildmeister) qui gère les changements autorisés dans /main/LATEST dans Clearcase ou /trunk dans SVN.
  • Le schéma de branches permanentes signifie que vous pouvez vérifier souvent sans craindre de casser la construction. Votre seule opportunité de casser la compilation est seulement après que votre correction de bogue ou votre fonctionnalité soit complète et que vous la fusionnez avec /main/LATEST.

L'option "Brancher quand c'est nécessaire" est un compromis qui peut convenir à de nombreux projets.

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

3) Profitez-en.

1voto

Englebart Points 11

Si vous utilisez ClearCase, veillez à utiliser le module UCM qui l'accompagne et les Composite Components.

Il rend tous vos branchements/fusions sans effort. Je parle de branches de réorganisation majeures qui s'étendent sur 6 mois et impliquent des dizaines de milliers de changements, y compris le renommage de répertoires, de fichiers, etc. qui résolvent automatiquement 99,9% des deltas.

De plus, nous n'utilisons que des vues SnapShot, et non des vues dynamiques. Nos vues instantanées se chargent plus rapidement que vous ne pouvez faire glisser et déposer (Windows) la même arborescence source depuis un lecteur réseau.

Le seul problème que j'ai avec UCM est que l'historique ne peut pas couvrir plusieurs composants. Si vous divisez un composant en plusieurs nouveaux composants, chaque nouveau composant commence à /main/0.

1 votes

Je fais souvent des livraisons/rebases en utilisant un dynamique car les fusions y sont beaucoup plus rapides et ne sont pas bloquées à cause d'une vue instantanée qui n'a pas été utilisée. entièrement mis à jour. Dans ce cas Je mets à jour ma vue instantanée avec le résultat de cette fusion et je continue à 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