Quels sont les concepts de base du «clearcase» que chaque développeur devrait connaître [fermé]

StackOverflow https://stackoverflow.com/questions/645008

  •  22-07-2019
  •  | 
  •  

Question

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

Était-ce utile?

La solution

Principaux concepts?

  • VCS centralisé (/ répété) : ClearCase se situe à mi-chemin entre le monde VCS centralisé (un ou plusieurs dépôts "centralisés" ou VOBS - Version Object Bases - chaque développeur doit pouvoir accéder à la validation ) et le monde distribué de VCS.
    Mais il prend également en charge un " répliqué " Mode permettant de répliquer un repo sur un site distant (MultiSite ClearCase), d’envoyer des deltas et de gérer les droits de propriété. (les droits de licence attachés à cela sont assez élevés cependant)

    Ce n'est pas un vrai " décentralisé " modèle, car il ne permet pas d’évolutions concurrentes en parallèle: Les branches sont maîtrisées dans un VOB ou un autre; vous ne pouvez vous connecter à la VOB principale que pour les branches maîtrisées à cet emplacement, même si vous n’avez accès en lecture seule qu’à une branche de n’importe quel réplica.

  • Stockage de version linéaire : chaque fichier et répertoire possède un historique linéaire; comme le DAG VCS ( graphe acyclique dirigé ) où l'histoire d'un Le fichier est lié à celui d'un répertoire lié à un commit.
    Cela signifie

    • lorsque vous comparez deux commits, vous devez comparer la liste de tous les fichiers et répertoires pour trouver le delta, car les commits ne sont pas atomiques d'un fichier ou d'un répertoire à l'autre, ce qui signifie qu'il n'y a pas de nom unique pour toutes les modifications apportées à tous les fichiers. constituer un delta logique.

    • Cela signifie également un fusion doit trouver un contributeur de base (pas toujours identique à un ancêtre commun) à travers l'exploration de l'histoire (voir point suivant).

      (Git se situe à l'extrémité opposée de ce spectre, à la fois décentralisé et orienté DAG:

      • si un noeud de son graphe a le même & id; id " en tant que nœud d'un commit différent, il n'est pas nécessaire d'explorer davantage: tous les sous-graphes sont garantis identiques
      • la fusion de deux branches est en réalité la fusion du contenu de deux noeuds dans un DAG: récursif et très rapide pour trouver un ancêtre commun)

alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif

  • Fusion à trois voies : pour fusionner deux versions, ClearCase doit rechercher un contributeur commun dans leur historique linéaire, qui peut être assez long pour une arborescence de versions complexe (branche / sous-branche / sous-sous-sous / branche, .. .) et la commande de base ClearCase fusionner fusionne un fichier ou un répertoire, mais ce n'est pas récursif. Cela concerne uniquement un fichier unique ou un seul répertoire sans ses fichiers ( ct findmerge est récursif)

  • centré sur le fichier (contrairement aux autres VCS récents plus centrés sur le référentiel): cela signifie que la validation est fichier par fichier et non pas "ensemble de fichiers modifiés": la transaction est au niveau du fichier. Un commit de plusieurs fichiers n'est pas atomique.
    (Presque tous les autres outils modernes sont "centrés sur le référentiel", avec une transaction de validation atomique, mais des systèmes de première génération tels que RCS, SCCS, CVS et m.La plupart des systèmes plus anciens n’ont pas cette fonctionnalité.)

  • géré par un identifiant : chaque fichier et répertoire possède un identifiant unique, ce qui signifie qu'ils peuvent être renommés à volonté: leur historique ne changera pas, car l'identifiant reste pour l'élément "élément". De plus, un répertoire détectera dans son historique tout ajout / suppression de fichier. Lorsqu'un fichier est " supprimé " ( rmname ), il ne le sait pas: seul le répertoire est notifié et crée une nouvelle version dans son historique, avec une liste de sous-éléments n'incluant pas le fichier supprimé.

(Créez deux fichiers avec la même taille et le même contenu, ils auront le même identifiant dans Git - une clé SHA1 - et ne seront stockés qu'une seule fois dans le référentiel Git! Ce n'est pas le cas dans ClearCase.
De plus, si deux fichiers avec le même chemin et le même nom sont créés dans deux branches différentes, leur identifiant étant différent, ces deux fichiers ne seront jamais fusionnés: ils sont appelés " evil twins ".

  • Les branches sont des citoyens de première classe : la plupart des VCS considèrent une branche et une balise comme identiques: un seul point de l'historique à partir duquel une nouvelle histoire linéaire peut se développer (branche) ou d'où une description est attachée (tag).
    Ce n'est pas le cas pour ClearCase, où une branche est un moyen de référencer un numéro de version. Tout numéro de version commence à 0 (simplement référencé dans ClearCase) à 1, 2, 3, etc. Chaque branche peut contenir une nouvelle liste de numéros de version (0, 1, 2, 3 à nouveau).
    Ceci diffère des autres systèmes où le numéro de version est unique et en croissance constante (comme les révisions dans SVN) ou tout simplement unique (comme les clés SHA1 dans Git).

  • auquel vous accédez par le chemin : pour accéder à une certaine version d'un fichier / répertoire, vous devez connaître son chemin d'accès étendu (composé de branches et de versions). Il s’appelle un "nom de chemin étendu": monFichier @@ / main / subBranch / Version .

(Git fait référence à tout via id - basé sur SHA1 -: version [ou commit], tree [ou version d'un répertoire] et blob [ou version d'un fichier, ou plutôt d'un contenu d'un fichier]. Il s'agit donc d'un "id-accessible" ou d'un "id-référencé".
Pour ClearCase, un identifiant fait référence à un "élément": un répertoire ou un fichier, quelle que soit sa version.)

  • verrou à la fois pessimiste et optimiste : (caisses réservées ou non réservées dans ClearCase): même un verrou pessimiste (caisse réservée) n'est pas véritablement pessimiste, car les autres utilisateurs peuvent toujours passer à la caisse ce fichier (bien qu'en "mode non réservé"): ils peuvent le modifier mais devront attendre que le premier utilisateur valide son fichier (archivage) ou annule la demande. Ensuite, ils fusionneront leur version de paiement de ce même fichier.
    (Remarque: une commande "réservée" peut déverrouiller son verrouillage et ne pas être réservée, ni par le propriétaire ni par l'administrateur.

  • branchement avantageux : une branche ne déclenche pas la copie de tous les fichiers. En réalité, cela ne déclenche rien: tout fichier non extrait restera dans sa branche d'origine. Seuls les fichiers modifiés auront leurs nouvelles versions stockées dans la branche déclarée.

  • Stockage de fichiers à plat : les fichiers VOB sont stockés dans un format propriétaire avec des fichiers simples. Ce n'est pas une base de données avec un langage de requête facile.

  • accès à un espace de travail réseau ou local :

    • L'espace de travail local passe par le contrôle du disque dur ("mise à jour" d'une vue instantanée).
    • l’espace de travail réseau utilise une vue dynamique, combinant des fichiers versionnés et des répertoires accessibles via le réseau (aucune copie locale, accès instantané) et des fichiers locaux (fichiers extraits ou fichiers privés). La combinaison de fichiers distants (versionnés) et locaux (privés) permet à une vue dynamique d’apparaître comme un disque dur classique (alors qu’en réalité, tout fichier "écrit" est stocké dans le stockage de vues associé).

Autres conseils

ClearCase est une bête à utiliser. Lent, buggy et cher. Certaines des choses que j'ai faites pour faire face à l'utilisation de CC sont:

  1. Mettez toujours de bons commentaires lorsque vous vous enregistrez.
  2. Utilisez une spécification de configuration commune et ne la modifiez pas très souvent.
  3. N'essayez jamais d'utiliser CC sur un réseau privé virtuel (VPN) ou une connexion réseau lente.
  4. Désactivez le chargement du médecin CC au démarrage.
  5. Ne déplacez pas les fichiers dans des répertoires différents.
  6. Planifiez au moins 2 minutes d'enregistrement par fichier.
  7. Les vues d'instantané sont lentes, mais les vues dynamiques sont plus lentes.
  8. Prenez l'habitude de vous enregistrer tôt et souvent car les fichiers réservés et les fusions sont pénibles.
  9. Tous les développeurs doivent extraire les fichiers non réservés par défaut.

Nous utilisons CC depuis un peu plus de quinze ans maintenant. Il a beaucoup de bonnes caractéristiques.

Tout notre développement se fait sur des branches; J'ai créé un couple aujourd'hui, pour différents ensembles de modifications. Lorsque je suis entré dans la succursale, un de mes collègues a passé en revue les modifications, puis fusionné dans / main / LATEST - ce qui se trouve être l’endroit où mon travail devait aller. Si cela avait été pour une version plus ancienne d’une branche, cela n’aurait pas été plus difficile.

Les fusions de mes branches temporaires étaient entièrement automatiques. personne n'a changé les fichiers sur lesquels j'ai travaillé pendant que je les ai extraites. Bien que, par défaut, les extractions soient réservées (verrouillées), vous pouvez toujours annuler l’exclusion ultérieure ou la créer sans réserve. Lorsque les modifications prennent plusieurs jours, la resynchronisation de ma branche temporaire avec la branche principale est simple et généralement automatique. L'outil de fusion est OK; Le plus gros problème pour moi est que mon serveur est à 1800 km de mon bureau (ou de chez moi), de sorte que X sur cette distance est un peu lent (mais pas de façon intolérable). Je n'ai pas utilisé de meilleur logiciel mergetool, mais cela ne dit peut-être pas grand-chose, car je n'ai pas utilisé d'autre outil de fusion graphique.

Les vues (vues dynamiques) sont rapides dans notre configuration. Je n'ai pas utilisé les vues instantanées, mais je ne travaille pas sous Windows quand je peux l'aider (notre équipe utilise des vues instantanées sous Windows; je ne comprends pas pourquoi). Nous avons des systèmes de branchement complexes, mais le développement principal est effectué sur / main / LATEST et le travail de publication est effectué sur une branche. Après l’AG, le travail de maintenance est effectué sur une branche spécifique à la version, puis fusionné vers / main / LATEST (via n’importe quelle version intermédiaire).

CC a besoin de bons administrateurs - nous les avons et nous avons la chance de le faire.

L’utilisation de CC n’est pas anodine, même si pour le moment, je trouve «git» aussi déconcertant que CC l’est pour ceux qui ne l’ont pas utilisé. Mais les bases sont à peu près les mêmes: extraction, modification, enregistrement, fusion, branche, etc. Les répertoires peuvent être branchés - avec prudence - et sont certainement contrôlés par la version. C'est inestimable.

Je ne vois pas le bureau passer de CC à tout moment.

Numéros de version intégrés - bons ou mauvais?

J'ai écrit:

  

Le plus gros problème que j'ai avec CC est qu’il n’intègre pas les numéros de version dans les fichiers sources - un problème que git a aussi, AFAICT. Je peux à moitié voir pourquoi; Je ne suis pas sûr d'aimer abandonner cette possibilité de suivi, cependant. Donc, j'utilise toujours RCS (pas même CVS) pour la plupart de mes travaux personnels. Un jour, je pourrais passer à git - mais ce sera une secousse et il faudra beaucoup de travail pour réoutiller les systèmes de release configurés autour de (SCCS et) RCS.

En réponse, @VonC note:

  

Nous avons toujours considéré cette pratique comme une pratique diabolique (mélanger des informations de métadonnées dans des données), en introduisant "fusion de l'enfer". Voir aussi Comment obtenir la version du fichier Clearcase dans un fichier Java . Bien entendu, vous pouvez utiliser un déclencheur pour la substitution de mot clé RCS ( Manuel Clearcase: Exemple de déclencheur d’enregistrement ) à condition que vous utilisiez un fusion appropriée gestionnaire .

Cette discussion met en évidence plusieurs problèmes qui se mélangent tous. Mon point de vue est presque archaïque, mais j’ai une justification derrière cela, et je vais prendre le temps de les écrire (foiré par la vie - il faudra peut-être plusieurs modifications pour y remédier).

Arrière-plan

J’ai appris le SCCS en 1984, au moment de la sortie de RCS (en 1983, je crois), mais SCCS était installé sur ma machine et Internet était au mieux naissant. J'ai déménagé de SCCS à RCS à contrecoeur dans lemilieu des années 90 car le format de date du SCCS utilise des chiffres à deux chiffres pour les années et il n’était pas clair si le SCCS serait fixé dans le temps (c’était). À certains égards, je n'aime pas autant le RCS que le SCCS, mais il a quelques points positifs. Commercialement, mon employeur utilisait le SCCS jusqu'au milieu de 1995, mais ils ont commencé à passer à Atria ClearCase à partir du début de 1994, en s'attaquant à des ensembles de produits distincts, un à la fois.

Première expérience ClearCase avec des déclencheurs - et fusion de l'enfer

Notre projet a migré plus tard, alors qu’il existait déjà une expérience de CC. En partie parce que j'y ai insisté, nous avons intégré les informations de contrôle de version dans les fichiers source via un déclencheur d'enregistrement. Cela a duré un certain temps - mais seulement un moment - car, comme le dit VonC, cela conduit à la fusion de l'enfer. Le problème est que si une version avec le tag / main / branche1 / N est fusionnée avec / main / M à partir de la version de base commune / main / B, les versions extraites des fichiers contiennent une seule ligne qui est modifiée dans chaque version - un conflit. Et ce conflit doit être résolu manuellement, plutôt que d'être traité automatiquement.

Maintenant, SCCS a des mots-clés d’ID. Les mots clés d'identification prennent deux formats, l'un pour les fichiers en cours de modification et l'autre pour les fichiers en cours de modification: 

Edit         Non-Edit
%I%          9.13
%E%          06/03/09
%Z%          @(#)
%M%          s.stderr.c

Si vous tentiez une fusion à 3 voies des versions modifiables des fichiers SCCS (avec la notation% x%), il n'y aurait aucun conflit sur les lignes contenant des métadonnées à moins que vous ne changiez les métadonnées sur ces lignes (par exemple en modifiant Dates% D% de style américain à% E% de style britannique - SCCS ne prend pas en charge les dates standard de type ISO 2009-03-15.)

RCS possède également un mécanisme de mots-clés, qui prend également deux formats, l'un pour les fichiers qui n'ont pas encore été insérés dans RCS et l'autre pour ceux qui ont: 

Original       After insertion
$Revision$     $Revision: 9.13 $
$Date$         $Date: 2009/03/06 06:52:26 $
$RCSfile$      $RCSfile: stderr.c,v $

La différence est entre un '$' suivant le mot clé et un ':', espace, texte, espace et enfin un '$'. Je n'ai pas suffisamment fusionné avec RCS pour savoir exactement ce qu'il fait avec les informations sur les mots clés, mais je remarque que, si les notations étendue et «contractée» étaient traitées comme équivalentes (quel que soit le contenu du matériau développé), la fusion pourrait alors se déroulent sans conflit, laissant la notation contractée dans le résultat de la fusion, qui serait élargie de manière appropriée lorsque le fichier résultant est récupéré après l'archivage.

Le problème de ClearCase est l’absence d’un gestionnaire de fusion approprié

Comme je l'ai indiqué dans ma discussion sur SCCS et RCS, si une fusion à 3 voies est effectuée en traitant les mots clés dans les formats corrects (contractés ou modifiables), il n'y a pas de conflit de fusion.

Le problème avec CC (de ce point de vue - de toute évidence, les développeurs de CC ne sont pas d’accord), c’est qu’il manque un système de gestion des mots-clés, et donc aussi un gestionnaire de fusion approprié.

S'il existait un système de gestion des mots-clés et un gestionnaire de fusion approprié, alors:

  • Le système incorporerait automatiquement les métadonnées dans des fichiers aux marqueurs appropriés.
  • Lors de la fusion, le système reconnaîtrait que les lignes contenant les marqueurs de métadonnées ne sont pas en conflit, à moins que les marqueurs ne soient modifiés différemment - le contenu des métadonnées sera ignoré.

L’inconvénient est qu’il faut soit un outil spécial de différence, qui reconnaît et traite spécifiquement les marqueurs de métadonnées, soit que les fichiers alimentés par cet outil soient canonisés (les marqueurs de métadonnées sont réduits à la forme neutre - $ Mot clé $ ou% K% en termes RCS et SCCS). Je suis sûr que ce peu de travail supplémentaire est la raison pour laquelle il n'est pas pris en charge, ce qui, à mon avis, était toujours à courte vue dans un système aussi puissant. Je n'ai pas d'attachement particulier aux notations RCS ou SCCS - les notations SCCS sont plus faciles à traiter à certains égards, mais elles sont essentiellement équivalentes - et toute notation équivalente pourrait être utilisée.

Pourquoi je pense toujours que les métadonnées du fichier sont bonnes

J'aime avoir les métadonnées dans le source code car mon code source (par opposition au code source de mon employeur) est distribué en dehors de la égide du code source système de contrôle de code. C’est-à-dire qu’il est principalement open source - je le mets à la disposition de tous. Si une personne signale un problème dans un fichier, en particulier dans un fichier qu’elle a modifié, je pense qu’il est utile de connaître son point de départ, ce qui est représenté par les métadonnées d’origine du fichier source.

Ici, SCCS a un avantage sur RCS: les formes développées des mots clés SCCS ne peuvent pas être distinguées du texte normal, alors que les mots clés RCS continuent de ressembler à des mots clés. Ainsi, si l’autre personne a importé le contenu dans son propre référentiel RCS, leurs métadonnées remplacent mes métadonnées, un problème qui ne se produit pas de la même manière avec SCCS (l’autre personne doit faire le travail pour écraser les métadonnées).

Par conséquent, même si quelqu'un prend une partie de mon code source et le modifie, il contient généralement suffisamment d'étiquettes pour en identifier l'origine, plutôt que de me laisser spéculer sur la version sur laquelle il est basé. Et cela, à son tour, permet de voir plus facilement quelles sont les parties du problème qui me concernent et celles qui les concernent.

Maintenant, dans la pratique, de la manière dont fonctionne l'open source, les gens ne migrent pas le code autant que vous le pensez. Ils ont tendance à s'en tenir à la version publiée assez étroitement, tout simplement parce que les déviations sont trop coûteuses lors de la prochaine publication officielle.

Je ne sais pas comment vous êtes censé déterminer la version de base d'un morceau de code source issu de votre travail et qui a été révisé depuis. Trouver la bonne version, cependant, semble être la solution. Si le code contient des empreintes digitales, cela peut être plus facile.

Voilà donc un résumé modéré des raisons pour lesquelles j'aime intégrer les informations de version dans les fichiers source. C'est en grande partie historique - SCCS et RCS l'ont fait tous les deux, et j'ai aimé le fait qu'ils l'aient fait. C'est peut-être une ancienne relique, quelque chose à dire adieu à l'ère du DVCS. Mais je ne suis pas encore totalement convaincu par cela. Cependant, il faudra peut-être encore plus d’essais pour expliquer les tenants et les aboutissants de mon mécanisme de gestion des versions afin de comprendre pourquoi je fais les choses comme je le fais.

Un aspect du raisonnement est que les fichiers de clés, tels que "stderr.c" et "stderr.h", sont utilisés par pratiquement tous mes programmes. Lorsque je publie un programme qui l'utilise, je m'assure simplement de disposer de la version la plus récente, à moins d'un changement d'interface nécessitant une version antérieure. Je n’ai pas eu ce problème depuis un moment (j’ai renommé systématiquement en 2003, ce qui a causé quelques problèmes transitoires, mais les scripts Perl m’ont permis d’implémenter facilement le changement de nom). Je ne sais pas combien de programmes utilisent ce code - entre 100 et 200 serait une estimation raisonnable. Les modifications de cette année (la série version 9.x) sont encore quelque peu spéculatives; Je n'ai finalement pas décidé de les garder ou non. Ils sont également internes à la mise en œuvre et n'affectent pas l'interface externe, je n'ai donc pas à me décider pour l'instant. Je ne suis pas sûr de savoir comment gérer ça avec git. Je ne souhaite pas intégrer le code de la bibliothèque dans une bibliothèque qui doit être installée avant de pouvoir créer mon logiciel - cela est trop onéreux pour mes clients. Ainsi, chaque programme continuera à être distribué avec une copie du code de la bibliothèque (un type différent d’onéreux), mais uniquement le code de la bibliothèque dont le programme a besoin, et non pas la bibliothèque entière. Et je choisis pour chaque programme les fonctions de bibliothèque utilisées. Donc, je n’exporterais pas un sous-arbre entier; en effet, le commit qui couvrait les dernières modifications du code de la bibliothèque n'avait généralement aucun lien avec le commit qui couvrait les dernières modifications du programme. Je ne suis même pas sûr que git devrait utiliser un référentiel pour la bibliothèque et un autre pour les programmes

Le HOWTO sur le contrôle des sources d'Eric est un excellent guide indépendant de l'outil.

J'ai travaillé avec Clearcase pendant presque 6 ans et je l’ai généralement trouvé tolérable. Il a une certaine courbe d'apprentissage, mais une fois que vous vous êtes habitué aux bizarreries, vous pouvez très bien vous en sortir. Un administrateur CC très compétent qui sait ce qu'il fait est essentiel pour tout, sauf les configurations triviales. À moins que vous n'en ayez un, les gens vont avoir des problèmes et assez vite, on parlera du "ClearCase". problème. Ensuite, la direction devra intervenir en passant à autre chose ne causant qu'une perte de temps pour toutes les personnes concernées. Le CC n’est pas un mauvais produit, c’est juste parfois mal compris.

Voici quelques concepts que j’ai jugés importants, dont certains ne sont pas uniquement orientés vers CC -

  • Une extraction n’a pas le même sens que la notion habituelle de CVS. Lorsque vous extrayez, vous verrouillez le fichier jusqu'à ce que vous l'enregistriez.
  • Il n'y a pas de problème de déplacement de fichiers. Enfait cela fonctionne parfaitement.
  • Les arborescences de versions sont essentielles pour comprendre ce qui se passe dans un fichier. Ils peuvent être assez encombrants pour les fichiers actifs, mais lorsque vous vous habituez à les regarder, ils deviennent un outil très utile, qui manque également d’autres outils de contrôle de code source, tels que SVN (dans une certaine mesure).
  • N'utilisez jamais de vues dynamiques. sa ne vaut pas la peine.
  • avant de créer une nouvelle branche, un nouveau flux ou un nouveau projet, informez-en votre administrateur afin de vous assurer que ce que vous créez est vraiment ce qui vous servira le mieux. Lorsque vous démarrez une nouvelle base de code, assurez-vous de bien planifier les flux et les projets dès le départ en planifiant. le changer plus tard est un vrai casse-tête, si possible.
  • Ajustez les privilèges des utilisateurs et configurez des déclencheurs pour les événements courants afin d'éviter les erreurs courantes ou d'appliquer des règles. Le serveur est très configurable et la plupart des problèmes que vous rencontrez sont probablement une solution raisonnable.
  • informez les développeurs des concepts de base aux opérations avancées. Un utilisateur expérimenté qui peut identifier le problème à l'aide de cleartool réduit la charge de l'administrateur.
  • Ne laissez pas de flux et de vues suspendus. Lorsqu'un développeur quitte le projet, demandez à quelqu'un de supprimer toutes les vues qu'il avait sur sa machine et de supprimer tous ses flux privés. Si vous ne maintenez pas votre serveur propre, cela aura pour conséquence que… il sera sale et, avec le temps, lent. Lorsque vous effectuez une "recherche de toutes les commandes". Sur tous les flux et toutes les vues, vous ne devriez pas voir les fichiers extraits par des personnes qui n'existent plus.
  • Exiger un " toujours refonder avant de livrer " Politique relative aux branches enfants pour éviter que les utilisateurs " interrompent le flux d'intégration " lors de la livraison de code en conflit avec les dernières modifications.
  • Intégration continue - ne laissez pas le flux d'intégration stagner pendant que chaque développeur ou chaque équipe travaille sur leur propre branche. Mandater une fois toutes les X fois, tout le monde doit au moins se réorienter vers la base de référence de l’intégration la plus récente, sinon pour apporter ses modifications stables. C’est effectivement très difficile à faire, en particulier avec de grands projets, mais l’autre alternative est "L’enfer de l’intégration". où, à la fin du mois, personne ne fait rien pendant 3 jours alors que de mauvaises personnes tentent de faire en sorte que tous les changements s’harmonisent

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

Une fois que vous aurez compris comment cela fonctionne (et que Clearcase le fait très bien, au point d’apporter même de petits changements en tant que branche et de fusionner, ce que je n’aurais jamais fait avec RCS ou CVS), trouver votre vie est beaucoup plus facile.

En quelque sorte hors sujet, mais - je ne connais presque 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 svn et git, il m'est impossible de penser à quelque chose qui me manque dans git ou subversion. C’est donc quelque chose que l’on doit savoir sur ClearCase - la plupart des développeurs sont vraiment ravis de travailler avec quelque chose de simple, comme subversion ou git (oui, même git est plus facile à comprendre), et même après avoir su effectuer les tâches les plus simples dans ClearCase, j’avais le sentiment constant que ClearCase agit contre moi, pas avec moi.

J'ai travaillé avec succès sur plusieurs projets de moyenne à grande taille, 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 décrivant l'utilisation du système de contrôle de version.

1) Recherchez ou créez un document sur les meilleures pratiques pour votre système de contrôle de version. Voici un pour le remplacement , à adapter à votre processus Clearcase. Tous les développeurs doivent adhérer au même plan de jeu.

En gros, décidez si vous allez "toujours créer une branche" ou "ne jamais créer de branche".

Régime Jamais de branche:

  • Le schéma "jamais de branche" correspond à ce que SourceSafe utilise: 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 créer un schéma:

  • Le schéma de toujours les branches signifie que les développeurs créent des branches pour chaque correction de bug ou ajout de fonctionnalité. Ce schéma est nécessaire pour les projets plus importants, ceux qui ont un responsable (buildmeister) qui gère les modifications autorisées dans / main / LATEST dans Clearcase ou / trunk dans SVN.
  • Le schéma de branche toujours signifie que vous pouvez enregistrer souvent sans crainte de casser le build. Votre seule opportunité d’interrompre la construction est une fois que votre correctif ou fonctionnalité est complète et que vous le fusionnez dans / main / LATEST.

"Brancher quand cela est nécessaire" est un compromis et peut fonctionner mieux pour de nombreux projets.

2) Avec Clearcase (et Subversion), vous devez apprendre à fusionner - la fusion est votre ami. Apprenez à utiliser les fonctionnalités de fusion de Clearcase ou à utiliser un outil tel que 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.

Si vous utilisez ClearCase, veillez à utiliser l'UCM qui l'accompagne ainsi que les composants composites.

Tous vos ramifications / fusions se font sans effort. Je parle de grandes branches de réorganisation qui fonctionnent pendant 6 mois et qui impliquent des dizaines de milliers de modifications, notamment le changement de nom de répertoire, le changement de nom de fichier, etc., qui résolvent automatiquement 99,9% des deltas.

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

Mon seul problème avec UCM, c’est que l’historique ne peut pas couvrir les composants. Si vous divisez un composant en plusieurs nouveaux composants, chaque nouveau composant commence par / main / 0.

La manière dont vous implémentez les outils de contrôle de version sur votre projet dépend de la taille et de la portée de votre projet et de l'expérience antérieure de l'équipe. ClearCase est un outil fantastique pour les grands projets, en nombre de développeurs et en taille. La gestion de la branche est l’un des aspects les plus importants de l’utilisation de l’outil de contrôle de version. sans ramification ni fusion, c’est une promenade de gâteau pendant le cycle de vie de votre projet. Mais vous ne pouvez pas éviter de fusionner pourquoi, car cela vous permet de verrouiller et de réaliser un développement parallèle fantastique.

Il existe une commande très pratique cleardescribe qui est utile à plusieurs reprises. Peut être utilisé pour obtenir les détails des étiquettes et des branches. La syntaxe est la suivante: 

cleardescribe lbtype:<LABELNAME>@\<VOB-NAME>
cleardescribe brtype:<BRANCHNAME>@\<VOB-NAME>

Plus précisément, cela vous permet de savoir quelle étiquette a été appliquée sur quelle branche et quelle branche est la branche parente d'une branche en question.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top