Implémentation de validations ClearCase essentiellement atomiques

Question

J'ai un projet pour lequel je dois effectuer plusieurs opérations sur une vue dynamique. Si l’une de ces opérations échoue ou si une erreur se produit dans le programme, je dois pouvoir annuler les commits.

La méthode la plus simple semble être de simplement mettre les commandes dans une file d’attente, puis, une fois le traitement terminé, d’exécuter la file d’attente. Cependant, je crains qu'un événement exceptionnel n'interrompe les validations et ne crée un ensemble de données incohérent sur le serveur.

Ou, en d'autres termes, je cherche un moyen de créer un "jeu de modifications" de style svn dans les vues dynamiques de Clearcase. Le langage de script que j'utilise est Perl, si cela compte.

Des idées?

Answer 1

Le caractère atomique de l'opération dans ClearCase étant au niveau du fichier, il n'existe pas d'équivalent strict d'un svn changeset ("une révision").

L'élément le plus proche d'un ensemble de modifications dans ClearCase est la notion d'activité (dans UCM) ou un ensemble d'étiquettes sur une collection de fichiers (une ligne de base UCM est en réalité plus proche, car elle représente des étiquettes que vous ne pouvez pas déplacer, sur une ensemble de fichiers prédéfini - composant UCM -)

Maintenant, UCM ou pas, je recommanderais:

• verrouiller la branche sur laquelle vous ferez les checkins (de cette façon, le vob est toujours accessible et personne ne tente d’ajouter d’autres versions sur cette branche particulière au cours de votre opération "atomique")
• faites vos checkins
• déverrouiller la branche

En cas de problème, tant que la branche est toujours verrouillée, vous pouvez " afficher les versions " des versions ajoutées. (Remarque: à utiliser avec précaution: un rmver ne peut pas être annulé)

• Note1: si vous ne travaillez pas dans UCM, vous devrez enregistrer toutes les versions archivées pour pouvoir les reproduire

• Note2: quand j'ai dit "verrouiller la branche", je voulais bien sûr dire: "verrouiller pour tout le monde sauf vous". ( -nusers yourLogin ). De cette façon, vous seul pouvez effectuer des archivages (cela s’applique à tous les fichiers LATEST de la branche sur laquelle vous travaillez (principal ou autre).

Le problème, avec cette approche, est ce que les clients (les autres utilisateurs disposant de leurs vues dynamiques dans LATEST sur la branche) verront lors de votre transaction atomique. < br> S'agissant de vues dynamiques , ils verront les fichiers archivés pendant leur archivage, un par un. Ce n'est peut-être pas bon, surtout s'il y a 200 fichiers et que le processus prend plus d'une minute.

Une solution serait que ces vues client définissent leur spécification de configuration comme suit:

element * .../myBranch/FREEZED_LATEST
element * .../myBranch/LATEST

Si vous ne faites pas de validation atomique changeset, le libellé FREEZED_LATEST n'existe pas et toutes les vues client affichent LATEST, comme elles le devraient. Tout enregistrement est immédiatement vu par tous.
Mais lors de votre commission atomique, vous pourriez:

• commencez par définir une étiquette FREEZED_LATEST sur tous les fichiers en cours (actuellement dans LATEST, c'est-à-dire)
  Cela signifie que tous les clients ne verront que ces versions spécifiques lors de la validation atomique
• faites votre travail (ou annulez-le: dans tous les cas, la branche est verrouillée et les spécifications de configuration des clients affichent toujours le même contenu "gelé")
• supprimez le libellé FREEZED_LATEST (tous les clients continuent à voir le nouveau DERNIER résultant de votre opération atomique et peuvent créer de nouvelles versions avec leurs propres extractions)

Answer 2

Avec la v7.1.1, ClearCase prend en charge les commits atomiques. Vous pourrez traiter un ensemble de fichiers comme une seule unité et les archiver ou les restaurer en fonction d’un critère donné.Pour plus d’informations, pour plus d’informations, voir https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm

Answer 3

Verrouillez tous les autres utilisateurs.

Faites une sauvegarde de votre serveur.

Faites vos commits.

Si quelque chose se passe mal, restaurez clearcase à partir de la sauvegarde.

Answer 4

Je n'ai pas utilisé Clearcase depuis des années, alors voici quelques pensées naïves et égarées.

Regardez devant vous pour déterminer si les fichiers sont désynchronisés.

Je verrouillerais tous les fichiers que vous êtes sur le point d’archiver avant de les archiver, et si vous n’arrivez pas à en verrouiller un, annulez tout le bazar avec un message utile.

Pouvez-vous " supprimer " un check-in? Ou alors, alors HEAD regarde une version précédente? Définissez votre annulation d'enregistrement.

Pouvez-vous créer une branche temporaire, procéder à l’enregistrement, puis fusionner / rebaser (ma terminologie est perdue ici). De cette façon, votre restauration est de tuer la branche. Bien que je me souvienne de mes collègues maudissant Clearcase à cause de ses ramifications.

En général, les actions en file d'attente sont excellentes, mais utilisez la file d'attente pour identifier les problèmes potentiels avant qu'ils ne surviennent. En outre, définissez vos actions et leurs critères d'annulation (UNDO). Ainsi, s'ils souhaitent faire quelque chose qui n'est pas pseudo-atomique, vous pouvez les avertir: "Cela pourrait devenir désordonné".