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

Question

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

VonC · Accepted Answer

Concepts de base ?

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 - Bases d'objets de version - chaque développeur doit accéder pour s’engager) et le monde distribué du VCS.
Mais il prend également en charge un mode "répliqué" vous permettant de répliquer un dépôt 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 est assez raide cependant)
Ce n’est pas un vrai modèle "décentralisé", car il ne permet pas d’évolutions parallèles : Les branches sont maîtrisées dans un VOB ou un autre; vous pouvez uniquement vous connecter au maître VOB pour les branches maîtrisées à cet emplacement, bien que vous ayez accès en lecture seule à toutes les branches de n'importe quel réplica.
stockage de version linéaire : chaque fichier et chaque répertoire ont un historique linéaire; il n'y a pas de relation directe entre eux comme le DAG VCS ( Directed Acyclic Graph ) où l'historique d'un fichier est lié à celui d'un répertoire lié à un commit.
Cela signifie
- lorsque vous comparez deux validations, vous devez comparer la liste de tous les fichiers et répertoires pour trouver le delta, car les validations ne sont pas atomiques d'un fichier à l'autre, ce qui signifie qu'il n'y a pas de nom unique pour toutes les modifications apportées à tous les fichiers constituant un fichier. delta logique.
- Cela signifie également qu'un fusion doit trouver un commun contributeur de base (pas toujours identique à un ancêtre commun) à travers l'exploration de l'histoire (voir point suivant).
  
  (Git est à l'opposé de ce spectre, étant à la fois décentralisé et orienté DAG:
  - si un nœud de son graphe a le même "id" qu'un nœud d'un commit différent, il n'a pas besoin d'explorer davantage: tous les sous-graphes sont garantis identiques
  - la fusion de deux branches correspond en réalité à la fusion du contenu de deux nœuds 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 trouver un contributeur commun dans leur historique linéaire, qui peut être assez long pour arborescence des versions complexe (branche/sous-branche/sous-sous/branche, ...), et la commande de base ClearCase merge fusionne un fichier ou un répertoire, mais elle n'est pas récursive. Cela n'affecte qu'un seul fichier, 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 "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 la plupart des autres. les systèmes plus anciens n’ont pas cette fonctionnalité.)
id-managed : chaque fichier et répertoire a un identifiant unique, ce qui signifie qu'ils peuvent être renommés à volonté: leur historique ne changera pas, car l'identifiant reste le même. "é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 seront stockés 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 d'accès 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: on les appelle " des jumeaux maléfiques ")

sont des citoyens de premier ordre : la plupart des systèmes de contrôle de version considèrent une branche et une balise comme identiques: un seul point de l’histoire à partir duquel une nouvelle histoire linéaire peut se développer (branche) ou d'où une description est attachée (tag).
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).
chemin-accédé : pour accéder à une certaine version d'un fichier/répertoire, vous devez connaître son chemin étendu (composé de branches et de versions). Cela s'appelle un "nom de chemin étendu": myFile@@/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’identité "id-allowed" ou "id-référencée".
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 extraire ce fichier (mais en "mode sans réserve"): ils peuvent le modifier mais devront attendre que le premier utilisateur valide son fichier (archivage) ou annule la demande. Ensuite, ils vont fusionner leur version de contrôle de ce même fichier.
(Remarque: une caisse "réservée" peut libérer son verrou et être laissée sans réserve, par le propriétaire ou par l'administrateur)
branchement pas cher : une branche ne déclenche pas une 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 à plat : les 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 local ou réseau :
- 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 est une vue dynamique combinant des fichiers versionnés et des répertoires avec accès 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 la vue associée).
Stockage déporté centralisé : [voir] Le stockage permet de conserver certaines données et d’éviter toute communication avec le référentiel central.
Un espace de travail peut avoir:
- un espace de stockage dispersé: comme les sous-répertoires .svn
- un stockage centralisé: comme le stockage de vues dans ClearCase, ils contiennent des informations sur les fichiers affichés par la vue, et ce stockage est unique pour une vue.
- un stockage déporté: le stockage ne fait pas partie de la vue/de l'espace de travail, mais peut être situé ailleurs sur l'ordinateur ou même à l'extérieur sur le LAN/WAN

(Git n'a pas de "stockage" en soi. Son .git est en fait tout le référentiel!)

orienté méta-données : toute "valeur-clé" peut être attachée à un fichier ou à un répertoire, mais ce couple de données n'est pas lui-même historisé: if la valeur change, elle remplace l'ancienne valeur.

(ce qui signifie que le mécanisme est en réalité plus faible que le système "propriétés" de SVN, où les propriétés peuvent avoir un historique;
Git à l’autre bout n’aime pas trop les méta-données)

Protection basée sur le système : le propriétaire et les droits associés à un fichier/répertoire ou à des référentiels sont basés sur la gestion des droits du système sous-jacent. Il n'y a pas de compte applicatif dans ClearCase, et le groupe d'utilisateurs est directement basé sur le groupe existant Windows ou Unix (ce qui est très difficile dans un environnement hétérogène, avec des clients Windows et un serveur Unix VOB!).

(SVN s'apparente davantage à une protection "basée sur serveur", où le serveur Apache peut obtenir un premier niveau de protection, mais doit être complété par des points d'ancrage pour obtenir un grain plus fin de droits.
Git n’a pas de gestion directe des droits et doit être contrôlé par des hooks lors de Push ou Pull entre les dépôts)

hooks disponibles : toute action ClearCase peut être la cible d'un hook, appelé déclencheur. Cela peut être une opération pré ou post.
CLI gérée : cleartool est l'interface de ligne de commande à partir de laquelle toutes les actions peuvent être effectuées.

Joshua · Answer

ClearCase est une bête à utiliser. Lent, buggy et cher. Certaines choses que j'ai faites pour utiliser CC sont les suivantes:

Mettez toujours de bons commentaires lorsque vous vous enregistrez.
Utilisez une spécification de configuration commune et ne la changez pas très souvent.
N'essayez jamais d'utiliser CC sur un VPN ou une connexion réseau lente.
Désactivez le chargement du médecin CC au démarrage.
Ne déplacez pas les fichiers dans des répertoires différents.
Planifiez au moins 2 minutes par fichier pour l'enregistrement.
Les vues instantanées sont lentes, mais les vues dynamiques sont plus lentes.
Prenez l'habitude de vérifier tôt et souvent parce que les fichiers réservés et les fusions sont pénibles.
Demandez à tous les développeurs d'extraire les fichiers non réservés par défaut.

Jonathan Leffler · Answer

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 j'ai vérifié dans la succursale, j'ai demandé à un collègue de passer en revue les modifications, puis de fusionner dans/main/LATEST - ce qui se trouve être l'endroit où mon travail devait aller. Si cela avait été pour une version plus ancienne sur 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 ne plus réserver l’extraction ultérieurement, ou créer l’extraction 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 mon domicile), 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 intimidant que CC l'est pour ceux qui ne l'utilisent pas. 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 changer 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 cependant pas sûr d’aimer abandonner cette possibilité de suivi. Donc, j'utilise toujours RCS (pas même CVS) pour la plupart de mes travaux personnels. Un jour, je changerai peut-être pour 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 un mal (mélanger des informations de métadonnées dans des données), en introduisant "fusionner 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 d'utiliser un gestionnaire de fusion approprié .

Cette discussion met en lumière 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 la compléter).

Contexte

J'ai appris le SCCS en 1984, à l'époque de la sortie de RCS (en 1983, je crois), mais SCCS était installé sur ma machine et Internet était au mieux naissant. Je suis passé de SCCS à RCS à contrecœur au milieu des années 90, car le format de date du SCCS utilise des chiffres à deux chiffres pendant des années et il n'était pas clair si SCCS serait fixé dans le temps (ce l'était). À certains égards, je n'aime pas autant RCS que 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 par un.

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

Notre projet a migré plus tard, alors qu'il y avait 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 - parce que, 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'identification. 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

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

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 - clairement, 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:.

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 - il ignorerait le contenu des métadonnées.
L’inconvénient est qu’il faut soit un outil spécial de différence qui reconnaît les marqueurs de métadonnées et les traite spécialement, soit obliger les fichiers alimentés vers l’outil de différence à être canonisés (les marqueurs de métadonnées sont réduits à la forme neutre - $ Keyword $ 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 à gérer à certains égards, mais elles sont essentiellement équivalentes - et toute notation équivalente pourrait être utilisée.

Pourquoi je pense toujours que les métadonnées dans le fichier sont bonnes.

J'aime avoir les métadonnées dans le code source car mon code source (par opposition au code source de mon employeur) est distribué en dehors de Aegis du système de contrôle du code source. 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 originales 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, ses métadonnées sont remplacées. mes métadonnées, un problème qui ne se produit pas de la même manière avec SCCS (l’autre personne doit s’efforcer d’é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 identifier d'où il vient, 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 la déviation est trop coûteuse 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 clé du succès. 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 de transition, 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 veux 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 - c'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 apportées au code de la bibliothèque n'avait généralement aucun lien avec la validation qui couvrait les dernières modifications du programme. Je ne sais même pas si git devrait utiliser un référentiel pour la bibliothèque et un autre pour les programmes qui l'utilisent, ou un référentiel plus grand commun. Et je ne migrerai pas vers git avant d'avoir compris cela.

OK - assez brouillant. Ce que j'ai travaille pour moi ce n'est pas nécessairement pour tout le monde. Cela n’impose pas de contraintes extraordinaires au VCS - mais cela nécessite des métadonnées de version intégrées dans les fichiers, et CC, Git et (je pense) SVN ont des problèmes avec cela. Cela signifie probablement que je suis celui qui a des problèmes - des blocages pour le passé perdu. Mais j'apprécie ce que le passé a à offrir. (Je peux m'en tirer parce que la plupart de mes codes ne sont pas branchés. Je ne sais pas quelle différence cela ferait.).

One aspect of the reasoning is that key files, such as 'stderr.c' and 'stderr.h', are used by essentially all my programs. When I release a program that uses it, I simply ensure I have the most recent version - unless there's been an interface change that requires a back-version. I haven't had that problem for a while now (I did a systematic renaming in 2003; that caused some transitional headaches, but Perl scripts allowed me to implement the renaming pretty easily). I don't know how many programs use that code - somewhere between 100 and 200 would be a fair guess. This year's set of changes (the version 9.x series) are still somewhat speculative; I haven't finally decided whether to keep them. They are also internal to the implementation and do not affect the external interface, so I don't have to make up my mind just yet. I'm not sure how to handle that using git. I don't want to build the library code into a library that must be installed before you can build my software - that's too onerous for my clients. So, each program will continue to be distributed with a copy of the library code (a different sort of onerous), but only the library code that the program needs, not the whole library. And I pick and choose for each program which library functions are used. So, I would not be exporting a whole sub-tree; indeed, the commit that covered the last changes in the library code is typically completely unrelated to the commit that covered the last changes in the program. I'm not even sure whether git should use one repository for the library and another for the programs that use it, or a common larger repository. And I won't be migrating to git until I do understand this.

OK - enough wittering. What I have works for me; it isn't necessarily for everyone. It does not make extraordinary demands on the VCS - but it does require version metadata embedded in the files, and CC and Git and (I think) SVN have issues with that. It probably means I'm the one with problems - hangups for the lost past. But I value what the past has to offer. (I can get away with it because most of my code is not branched. I'm not sure how much difference branching would make.)

Jason Punyon · Answer

Le Control Source HOWTO d'Eric est un excellent guide indépendant de l'outil.

Matt Curtis · Answer

Comment utiliser git sur ClearCase!

shoosh · Answer

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 on parlera assez vite du problème "ClearCase". 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 trouvés importants, certains d'entre eux ne sont pas uniquement orientés CC -

Un check-out est différent de la notion habituelle de check-out de type CVS. Lorsque vous extrayez, vous verrouillez le fichier jusqu'à ce que vous l'enregistriez.
Il n'y a pas de problème pour déplacer des fichiers. En fait, cela fonctionne parfaitement.
Les arborescences de versions sont essentielles pour comprendre ce qui est arrivé à un fichier. Ils peuvent être assez compliqués pour les fichiers actifs, mais quand vous vous habituez à les regarder, ils deviennent un outil très utile et un outil qui manque énormément dans les autres outils de contrôle de source tels que SVN (dans une certaine mesure).
N'utilisez en aucun cas des vues dynamiques. ça ne vaut pas le coup.
avant de créer une nouvelle branche, un nouveau flux ou un nouveau projet, renseignez-vous auprès de votre administrateur pour 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.
Réglez avec précision 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.
éduquez les développeurs sur tout, 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 travail de l'administrateur.
Ne laissez pas de ruisseaux ni 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 extractions" sur tous les flux et toutes les vues, vous ne devriez pas voir les fichiers extraits par des personnes qui n'existent plus.
Attribuez aux règles enfants une stratégie de "refonte systématique avant livraison" pour éviter que des personnes "interrompent le flux d'intégration" lors de la livraison d'un code en conflit avec les modifications récentes.
Intégration continue - ne laissez pas le flux d'intégration stagner pendant que chaque développeur ou équipe travaille sur sa 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 en effet 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 qu'un groupe médiocre tente de faire en sorte que tous les changements s'harmonisent

paxdiablo · Answer

À mon avis, la création de branches et la fusion sont les concepts les plus importants dans 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 se fait (et que Clearcase le fait très bien, au point que nous effectuons même de petits changements en tant que branche et que nous fusionnons, ce que je n'aurais jamais fait avec RCS ou CVS), vous retrouverez votre vie est beaucoup plus facile.

siddhadev · Answer

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 . 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 toujours le sentiment que ClearCase agit contre moi, pas avec moi.

thompsongunner · Answer

J'ai travaillé avec succès sur plusieurs projets de moyenne à grande taille, utilisant 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 comment vous utiliserez le 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 Subversion , adaptez-le à 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'.

Jamais régime de branche:

Le schéma "jamais de branche" correspond à ce que SourceSafe utilise: les fichiers sont verrouillés lors de la vérification et deviennent disponibles lors de l’archivage. Ce schéma convient aux petits projets d’équipe (1 ou 2 développeurs).

Toujours régime de branche:

Le schéma toujours de branche 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, ceux qui ont un responsable (buildmeister) qui gère les modifications autorisées dans/main/LATEST dans Clearcase ou/trunk dans SVN.
Le système toujours de branche signifie que vous pouvez enregistrer souvent sans crainte de casser la construction. 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.

Le «branchement au besoin» est un compromis et peut fonctionner mieux pour de nombreux projets.

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

Englebart · Answer

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

Cela rend toutes vos branches/fusions sans effort… .. Je parle de branches de réorganisation majeures qui durent 6 mois et qui impliquent des dizaines de milliers de modifications, notamment le changement de nom de répertoire, de fichier, etc.

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

Le seul reproche que j'ai à propos d'UCM 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.

eeerahul · Answer

Il existe une commande très pratique cleardescribe qui est utile plusieurs fois. 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>

Cela vous permet notamment de savoir que l'étiquette a été appliquée sur quelle branche et que la branche est la branche parente d'une branche en question.

Robert · Answer

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 des gâteaux pendant le cycle de vie de votre projet. Mais vous ne pouvez pas éviter de fusionner pourquoi parce que cela vous permet de verrouiller et de développer de manière fantastique.