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

Question

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

Answer 1

Core des concepts ?

• VCS centralisé(-répliqué) : ClearCase se situe à mi-chemin entre le monde VCS centralisé (un ou plusieurs repos ou VOBS - Version Object Bases - "centralisés" auxquels chaque développeur doit accéder pour commettre) et le monde VCS distribué.
  Mais il supporte également un mode "répliqué" vous permettant de répliquer un repo dans un site distant (MultiSite ClearCase), d'envoyer des deltas, et de gérer la propriété. (les frais de licence liés à ce mode sont assez élevés).
  Il ne s'agit pas d'un véritable modèle "décentralisé", puisqu'il ne permet pas le fonctionnement en parallèle. concurrentes les évolutions : Les branches sont maîtrisées dans une VOB ou une autre ; vous ne pouvez vous enregistrer dans la VOB maître que pour les branches qui y sont maîtrisées, mais vous avez un accès en lecture seule à n'importe quelle branche de n'importe quelle réplique.

• stockage de la version linéaire : chaque fichier et répertoire a une histoire linéaire ; il n'y a pas de relation directe entre eux comme le DAG VCS ( Graphique acyclique dirigé ) où l'historique d'un fichier est lié à celui d'un répertoire lié à un commit.
  Cela signifie que

  • 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 entre les fichiers ou les répertoires, ce qui signifie qu'il n'y a pas de nom unique pour toutes les modifications apportées à tous les fichiers qui constituent un delta logique.

  • Cela signifie également un fusionner doivent trouver un point commun _contributeur de base_ (ce qui n'est pas toujours synonyme d'ancêtre commun) par l'exploration de l'histoire (voir le 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 est en fait la fusion du contenu de deux nœuds dans un DAG : récursif et très rapide pour trouver un ancêtre commun)

texte alternatif 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 de base commun dans leur historique linéaire, qui peut être assez long pour un arbre de version complexe (branche/sous-branche/sous-sous-branche, ...), et l'option de base Fusion de ClearCase fusionne un fichier ou un répertoire, mais elle n'est pas récursive. Elle n'affecte qu'un seul fichier, ou un seul répertoire sans ses fichiers ( ct findmerge est récursif)

• centré sur les fichiers (par opposition à l'autre VCS récent plus centré sur le référentiel) : cela signifie que le commit 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 moderne est "repository centric", avec une transaction commit atomique, mais les systèmes de première génération comme RCS, SCCS, CVS, et la plupart des autres systèmes plus anciens n'ont pas cette fonctionnalité).

• géré par l'id : chaque fichier et répertoire a un identifiant unique, ce qui signifie qu'ils peuvent être renommés à volonté : leur historique ne changera pas puisque l'identifiant reste pour l'"é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 ne comprenant pas le fichier supprimé.

(Créez deux fichiers ayant la même taille et le même contenu, ils obtiendront le même identifiant dans Git -- une clé SHA1 -- et ne seront stockés qu'une seule fois dans le repo Git ! Ce n'est pas le cas dans ClearCase.
De plus, si deux fichiers ayant le même chemin et le même nom sont créés dans deux branches différentes, le fait que leur identifiant soit différent signifie que ces deux fichiers ne seront jamais fusionnés : ils sont appelés " jumeaux maléfiques ")

• les branches sont des citoyens de première classe La plupart des VCS considèrent qu'une branche et une balise sont identiques : un point unique dans l'histoire à partir duquel une nouvelle histoire linéaire peut se développer (branche) ou à partir duquel une description est attachée (balise).
  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 (juste référencé dans ClearCase) pour passer à 1, 2, 3, et ainsi de suite. Chaque branche peut contenir une nouvelle liste de numéros de version (0, 1, 2, 3 à nouveau).
  C'est différent des autres systèmes où le numéro de version est unique et toujours croissant (comme les révisions dans SVN), ou simplement unique (comme les clés SHA1 dans Git).

• chemin d'accès Pour accéder à une certaine version d'un fichier/répertoire, vous devez connaître son chemin étendu (composé de branches et de versions). C'est ce qu'on appelle un "nom de chemin étendu" : myFile@@/main/subBranch/Version .

(Git fait référence à tout par le biais d'un identifiant -- basé sur SHA1 -- : version [ou commit], arbre [ou version d'un répertoire] et blob [ou version d'un fichier, ou plutôt d'une contenu d'un dossier]. Il s'agit donc de "id-accessed" ou "id-referenced".
Pour ClearCase, un id fait référence à un "élément" : un répertoire ou un fichier, quelle que soit sa version).

• la serrure pessimiste et la serrure optimiste (extractions réservées ou non réservées dans ClearCase) : même un verrouillage pessimiste (extraction réservée) n'est pas vraiment pessimiste, puisque d'autres utilisateurs peuvent toujours extraire ce fichier (bien qu'en "mode non réservé") : ils peuvent le modifier mais devront attendre que le premier utilisateur livre son fichier (checkin) ou annule la demande. Ensuite, ils fusionneront leur version checkout de ce même fichier.
  (Remarque : une caisse "réservée" peut être déverrouillée et rendue non réservée, soit par le propriétaire, soit par l'administrateur).

• Branchements bon marché : une branche ne déclenche pas une copie de tous les fichiers. En fait, elle ne déclenche rien : tout fichier non vérifié restera dans sa branche d'origine. Seuls les fichiers modifiés verront leurs nouvelles versions stockées dans la branche déclarée.

• stockage de dossiers plats Les VOBs sont stockés dans un format propriétaire avec des fichiers simples. Il ne s'agit pas d'une base de données avec un langage d'interrogation facile.

• accès à l'espace de travail local ou en réseau :

  • l'espace de travail local se fait par extraction sur le disque dur ("mise à jour" d'une vue instantanée).
  • L'espace de travail en réseau se présente sous la forme d'une vue dynamique, combinant des fichiers et des répertoires versionnés accessibles par le réseau (pas de copie locale, accès instantané) et des fichiers locaux (ceux qui sont extraits ou les 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 la vue associée).

• stockage centralisé des déportés : [Le stockage est là pour garder certaines données et éviter toute communication avec le référentiel central.
  un espace de travail peut avoir :

  • un stockage dispersé : comme le .svn des sous-répertoires un peu partout
  • un stockage centralisé : comme le stockage des 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 lui-même, mais peut être situé ailleurs sur l'ordinateur ou même à l'extérieur sur le LAN/WAN.

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

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

(ce qui signifie que le mécanisme est en fait plus faible que le système de "propriétés" de SVN, où les propriétés peuvent avoir un historique ;
Git, à l'autre bout, n'est pas très enthousiaste à l'égard des 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 dépôts 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 assez difficile dans un environnement hétérogène, avec des clients Windows et un serveur VOB Unix !)

(SVN est plutôt une protection "basée sur le serveur", où le serveur Apache peut obtenir un premier niveau de protection, mais doit être complété par des hooks pour avoir un grain de droits plus fin.
Git n'a pas de gestion directe des droits et doit être contrôlé par des hooks pendant le push ou le pull entre les dépôts).

• crochets disponibles : toute action ClearCase peut être la cible d'un hook, appelé trigger. Il peut s'agir d'une pré ou post opération.

• géré par CLI Cleartool est l'interface de ligne de commande à partir de laquelle toutes les actions peuvent être effectuées.

Answer 2

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

1. Mettez toujours de bons commentaires lorsque vous effectuez un check-in.
2. Utilisez une spécification de configuration commune et ne la modifiez pas très souvent.
3. N'essayez jamais d'utiliser CC via un VPN ou une connexion réseau lente.
4. Désactivez le chargement du CC doctor au démarrage.
5. Ne déplacez pas les fichiers vers différents répertoires.
6. Prévoyez au moins 2 minutes par fichier pour le check-in.
7. Les vues en snapshot sont lentes, mais les vues dynamiques le sont encore plus.
8. Prenez l'habitude en développement de faire des check-in tôt et souvent car les fichiers réservés et les fusions sont douloureux.
9. Amenez tous les développeurs à vérifier les fichiers en mode non réservé par défaut.

Answer 3

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

Tout notre développement se fait sur des branches ; j'en ai créé deux aujourd'hui, pour deux ensembles différents de changements. Après avoir vérifié la branche, j'ai demandé à un collègue de revoir les changements, puis j'ai fusionné dans /main/LATEST - 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 à partir de mes branches temporaires étaient entièrement automatiques ; personne n'avait modifié les fichiers sur lesquels je travaillais pendant que je les faisais vérifier. Bien que par défaut les extractions soient réservées (verrouillées), vous pouvez toujours annuler la réservation de l'extraction plus tard, ou créer l'extraction sans réservation. Lorsque les modifications prennent plusieurs jours, la resynchronisation de ma branche temporaire avec la branche principale est facile et généralement automatique. L'outil de fusion est correct ; le plus gros problème pour moi est que ma machine serveur est à environ 1800 miles de mon bureau (ou de ma maison), de sorte que X sur cette distance est un peu lent (mais pas intolérablement). Je n'ai pas utilisé de meilleur mergetool, mais cela ne veut peut-être pas dire grand chose puisque je n'ai pas utilisé d'autre mergetool graphique.

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

Le CC a besoin de bons administrateurs - nous en avons et nous avons la chance d'en avoir.

CC n'est pas facile à utiliser, bien qu'en ce moment, je trouve "git" aussi intimidant que CC pour ceux qui ne l'ont pas utilisé. Mais les bases sont à peu près les mêmes - checkout, change, checkin, merge, branch, et ainsi de suite. Les répertoires peuvent être branchés - avec précaution - et sont certainement contrôlés en version. C'est inestimable.

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

---

Numéros de version intégrés - bien ou mal ?

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 comprends à moitié pourquoi ; je ne suis pas sûr d'aimer renoncer à cette traçabilité, cependant. Ainsi, j'utilise toujours RCS (même pas CVS) pour la plupart de mes travaux personnels. Un jour, je passerai peut-être à git - mais ce sera un choc et il faudra beaucoup de travail pour réorganiser les systèmes de publication configurés autour de (SCCS et) RCS.

En réponse, @VonC note :

Nous avons toujours considéré cette pratique comme maléfique (mélanger les informations de méta-données aux données), introduisant "l'enfer de la fusion". Voir aussi Comment obtenir la version du fichier Clearcase à l'intérieur d'un fichier Java . Bien sûr, vous pouvez utiliser un déclencheur pour la substitution de mots-clés RCS ( Manuel Clearcase : Exemple de déclencheur Checkin ) à condition que vous utilisiez un gestionnaire de fusion approprié .

Cette discussion soulève plusieurs questions, qui sont toutes mélangées. Mon point de vue frise l'archaïsme, mais il est fondé sur un raisonnement, et je vais prendre le temps de l'écrire (il a été chamboulé par la vie - il faudra peut-être plusieurs éditions pour le terminer).

Contexte

J'ai appris SCCS en 1984, à peu près au moment où RCS est sorti (1983, je crois), mais SCCS était sur ma machine et l'internet était au mieux naissant. Je suis passé de SCCS à RCS à contrecoeur au milieu des années 90 parce que le format de date de SCCS utilise des chiffres à deux chiffres pour les années et il n'était pas clair si SCCS serait universellement corrigé à temps (il l'a été). A certains égards, je n'aime pas RCS autant que SCCS, mais il a quelques bons points. Commercialement, mon employeur a utilisé SCCS jusqu'à la mi-1995, mais ils ont commencé à passer à Atria ClearCase dès le début de 1994, en s'attaquant à des ensembles de produits distincts un par un.

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

Notre projet a migré plus tard, alors que nous avions déjà une certaine expérience de CC. En partie parce que j'ai insisté sur ce point, nous avons intégré des informations de contrôle de version dans les fichiers sources par le biais d'un déclencheur check-in. Cela a duré un certain temps - mais seulement un certain temps - car, comme le dit VonC, cela conduit à l'enfer de la fusion. Le problème est que si une version avec l'étiquette /main/branch1/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 a été modifiée dans chaque version - un conflit. Et ce conflit doit être résolu manuellement, au lieu d'être géré automatiquement.

Maintenant, le SCCS a des mots-clés d'identification. Les mots-clés ID ont deux formats, l'un pour les fichiers en cours de modification et l'autre pour les fichiers qui ne sont pas en cours de modification :

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

Si vous tentez une fusion à trois des versions modifiables des fichiers SCCS (avec la notation %x%), il n'y aura pas de conflits sur les lignes contenant des métadonnées, à moins que vous ne modifiiez les métadonnées sur ces lignes (par exemple en passant des dates %D% de style américain aux dates %E% de style britannique - SCCS ne prend pas en charge les dates 2009-03-15 de style ISO en standard).

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

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 ':', un espace, du texte, un espace et enfin un '$'. Je n'ai pas fait assez de fusions avec RCS pour être sûr de ce qu'il fait avec les informations des mots-clés, mais je note que s'il traite les notations étendues et "contractées" comme équivalentes (indépendamment du contenu du matériel étendu), alors la fusion pourrait avoir lieu sans conflit, laissant la notation contractée dans la sortie de la fusion, qui serait correctement étendue lorsque le fichier résultant est récupéré après vérification.

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 la fusion à trois est effectuée en traitant les mots-clés dans les formats corrects (contractés ou modifiables), alors il n'y a pas de conflit de fusion.

Le problème avec CC (de ce point de vue - clairement, les implémenteurs de CC ne sont pas d'accord) est qu'il manque un système pour gérer les mots-clés, et donc aussi un gestionnaire de fusion approprié.

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

• Le système intègre automatiquement les métadonnées dans les fichiers aux points de repère appropriés.
• Lors de la fusion, le système reconnaîtrait que les lignes avec les marqueurs de métadonnées ne sont pas en conflit, à moins que les marqueurs aient été modifiés différemment - il ignorerait le contenu des métadonnées.

L'inconvénient de cette méthode est qu'elle nécessite soit un outil de différenciation spécial qui reconnaît les marqueurs de métadonnées et les traite de manière particulière, soit que les fichiers fournis à l'outil de différenciation soient 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 petit travail supplémentaire est la raison pour laquelle il n'est pas supporté, quelque chose que j'ai toujours pensé être à 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 à manipuler à 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 parce que mon code source (par opposition au code source de mon employeur) est distribué en dehors de l'espace de travail de l'entreprise. 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 et de chacun. Si quelqu'un signale un problème dans un fichier, en particulier dans un fichier qu'il a modifié, je pense qu'il est utile de savoir d'où il est parti, et cela est représenté par les métadonnées originales du fichier source.

Ici, SCCS a un avantage par rapport à RCS : les formes développées des mots-clés SCCS sont indiscernables du texte ordinaire, tandis que les mots-clés RCS continuent à ressembler à des mots-clés, de sorte que si l'autre personne a importé le matériel dans son propre dépôt RCS, ses métadonnées remplacent mes métadonnées, un problème qui ne se produit pas avec SCCS de la même manière (l'autre personne doit faire un travail pour écraser les métadonnées).

Par conséquent, même si quelqu'un prend un morceau de mon code source et le modifie, il y a 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 parties du problème sont de mon fait et quelles parties sont de leur fait.

En pratique, le fonctionnement de l'open source fait que les gens ne migrent pas le code autant qu'on pourrait le croire. Ils ont tendance à s'en tenir à la version publiée, tout simplement parce que s'écarter est trop coûteux lors de la prochaine version officielle.

Je ne sais pas comment vous êtes censé déterminer la version de base d'un morceau de code source qui provient de votre travail et qui a été révisé depuis. Trouver la version correcte, cependant, semble être la clé pour le faire, et s'il y a des empreintes digitales dans le code, alors cela peut être plus facile.

C'est donc un résumé modéré de la raison pour laquelle j'aime intégrer les informations de version dans les fichiers sources. C'est en grande partie historique - SCCS et RCS le faisaient tous les deux, et j'aimais le fait qu'ils le fassent. C'est peut-être une relique ancienne, quelque chose qui doit être abandonné à l'ère du DVCS. Mais je ne suis pas encore totalement convaincu de cela. Cependant, il faudrait peut-être encore plus d'un essai pour expliquer les tenants et aboutissants de mon mécanisme de gestion des versions pour comprendre pourquoi je fais les choses comme je les fais.

Un aspect du raisonnement est que les fichiers clés, tels que 'stderr.c' et 'stderr.h', sont utilisés par pratiquement tous mes programmes. Lorsque je publie un programme qui les utilise, je m'assure simplement que j'ai la version la plus récente - à moins qu'un changement d'interface ne nécessite une rétroversion. Je n'ai pas eu ce problème depuis un certain temps maintenant (j'ai procédé à un renommage systématique en 2003 ; cela a causé quelques maux de tête transitoires, mais Perl scripts m'a permis de mettre en œuvre le renommage assez facilement). Je ne sais pas combien de programmes utilisent ce code - quelque part entre 100 et 200 serait une estimation juste. L'ensemble des changements de cette année (la série des versions 9.x) est encore quelque peu spéculatif ; je n'ai pas encore décidé s'il fallait les conserver. Ils sont également internes à l'implémentation et n'affectent pas l'interface externe, donc je n'ai pas à me décider tout de suite. Je ne suis pas sûr de savoir comment gérer cela en utilisant git. Je ne veux pas intégrer le code de la bibliothèque dans une bibliothèque qui doit être installée avant que vous puissiez construire 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 (une autre sorte de fardeau), mais seulement le code de la bibliothèque dont le programme a besoin, pas toute la bibliothèque. Et je choisis pour chaque programme les fonctions de la bibliothèque qui sont utilisées. Ainsi, je n'exporterais pas un sous-arbre entier ; en effet, le commit qui a couvert les derniers changements dans le code de la bibliothèque n'est généralement pas du tout lié au commit qui a couvert les derniers changements dans le programme. Je ne suis même pas sûr que git doive utiliser un dépôt pour la bibliothèque et un autre pour les programmes qui l'utilisent, ou un dépôt commun plus large. Et je ne migrerais pas vers git avant d'avoir compris cela.

OK - assez de bavardages. Ce que j'ai fonctionne pour moi ; ce n'est pas nécessairement pour tout le monde. Il n'impose pas de demandes extraordinaires au VCS - mais il 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 c'est moi qui ai des problèmes - des blocages pour un passé perdu. Mais j'apprécie ce que le passé a à offrir. (Je peux m'en tirer parce que la plupart de mon code n'est pas ramifié. Je ne suis pas sûr de la différence qu'apporterait le branchement).

Answer 4

Le guide d'Eric sur le contrôle de source est un excellent guide qui est indépendant de l'outil.

Answer 5

J'ai travaillé avec ClearCase pendant une bonne partie de 6 ans et j'ai généralement trouvé ça supportable. Il a certainement une courbe d'apprentissage mais une fois que vous vous habituez aux particularités, vous pouvez travailler assez facilement avec. Un administrateur CC compétent qui sait ce qu'il fait est essentiel pour autre chose que des configurations triviales. À moins d'en avoir un, les gens vont rencontrer des problèmes et très rapidement il sera question du problème "ClearCase". Ensuite, la direction devra intervenir en passant à autre chose, entraînant ainsi une perte de temps pour tout le monde impliqué. 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 concernent pas uniquement CC -

• Un check-out est différent de la notion habituelle d'un check-out à la façon de CVS. Lorsque vous faites un check-out, vous verrouillez le fichier jusqu'à ce que vous le check-in.
• Il n'y a aucun problème avec le déplacement des fichiers. En fait, cela fonctionne parfaitement.
• Les arbres de versions sont essentiels pour comprendre ce qui s'est passé avec un fichier. Ils peuvent devenir assez désordonnés pour des fichiers actifs mais une fois que vous avez l'habitude de les consulter, cela devient un outil très pratique et un outil très manquant dans d'autres outils de contrôle de source tels que SVN (dans une certaine mesure).
• Ne pas utiliser les vues dynamiques en aucune circonstance. Ce n'en vaut pas la peine.
• Avant de créer une nouvelle branche, stream ou projet, consultez votre administrateur pour vous assurer que ce que vous créez est vraiment ce qui vous servira le mieux. Lorsque vous commencez une nouvelle base de code, assurez-vous d'obtenir la mise en page des streams et des projets correcte dès le départ en planifiant à l'avance. Le changer plus tard est un vrai casse-tête si même possible.
• Ajustez les privilèges des utilisateurs et configurez des déclencheurs pour les événements courants afin de prévenir les erreurs courantes ou d'appliquer des politiques. Le serveur est très configurable et la plupart des problèmes que vous rencontrez là-bas ont 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 trouver quel est le problème en utilisant cleartool allège la charge sur l'administrateur.
• Ne laissez pas de streams et de vues pendantes. Lorsqu'un développeur quitte le projet, ayez quelqu'un pour supprimer toutes les vues qu'il avait sur sa machine et supprimer tous ses streams privés. Ne pas garder votre serveur propre aboutira à... ce qu'il soit sale et avec le temps, lent. Lorsque vous faites un "trouver tous les checkouts" sur tous les streams et vues, vous ne devriez pas voir de fichiers en cours de check-out par des personnes qui n'existent plus.
• Exigez une politique "toujours rebase avant de livrer" pour les branches enfant afin d'éviter que les gens "cassent le stream d'intégration" en livrant du code qui entre en conflit avec des changements récents.
• Intégration continue - ne laissez pas le stream d'intégration stagner pendant que chaque développeur ou équipe travaille sur sa propre branche. Exigez qu'une fois tous les X temps, tout le monde doit au moins rebase sur la baseline d'intégration la plus récente, sinon livrer leurs changements stables. C'est en effet très difficile à faire, surtout avec de gros projets, mais l'autre alternative est "l'enfer de l'intégration" où à la fin du mois, personne ne fait quoi que ce soit pendant 3 jours pendant qu'un pauvre bougre essaie de faire en sorte que tous les changements s'emboîtent.