ClearCase: Comment revenir à la version de base antérieure?

Question

Comment puis-je revenir à une base de référence antérieure? Nous avons un projet de développement parallèle UCM (multi-flux). Chaque développeur dispose d'une vue instantanée sur le flux d'intégration de Project. Les développeurs veulent voir la version antérieure de l'application dans leurs vues instantanées afin qu'ils puissent déboguer la première version de l'application pour trouver des bogues.

Lorsque je souhaite modifier les lignes de base d'une vue d'instantané existante, l'option clearcase ne me le permet pas. Alors, comment puis-je faire cela?

Answer 1

Étant donné que vous utilisez le terme Ligne de base, je suppose que vous utilisez UCM.

Dans un flux, vous ne pouvez pas revenir en arrière sur une ligne de base.

Une possibilité consiste à créer un flux parallèle, avec comme base la ligne de base souhaitée: c'est le moyen le plus rapide.

---

Une fois les modifications de ce nouveau flux, vous pouvez faire une nouvelle rebasage pour changer la ligne de base de la fondation, mais seulement si cette nouvelle rebasage utilise une plus référence récente du flux parent (pas une base plus)

---

pour vos besoins spécifiques, je vous recommande un instantané non-UCM avec une règle simple

element * thePreviousBaseline 

pour le développeur d'avoir:

• son/sa vue actuelle UCM pour le développement (toujours mis sur la dernière d'une branche associée à un flux)
• une seconde vue snasphot fixé à quelque base qu'il/elle a besoin.

Cette seconde vue instantanée est complètement non liée au projet UCM et profite de la « pleine » nature de la ligne de base (ne vérifiez que votre base a été mis en « plein », et non « supplémentaires ».Si elle est « progressive », il suffit de changer le type et le mettre à jour à plein)

Ainsi, à côté de votre instantané actuel vue UCM, vous pouvez créer partout où vous voulez une vue non-snasphot:

cleartool mkview -snap -tag mylogin_myComponentname_csl_snap -vws myPathToViewStorage myPathToRootView 
cd myPathToRootView 
cleartool edcs 
[add the selection rule: element * myOlderBaseline] 
[add the load rule at the end: 'load /myVob_Including_MyComponent] 
[save, type 'yes'] 

Ce est bien pour la consultation/exécution, mais si vous avez besoin de patcher (que je dois écrire, vérifier et dans certains fichiers), alors je recommanderais un flux UCM par référence à patcher. De cette manière, le flux représente clairement l'effort de patch pour une ligne de base donnée. Il ne devrait pas être trop grand nombre d'entre eux, à moins que vous mettez dans la production d'une nouvelle version de votre application toutes les cinq minutes ... ce qui n'est pas conseillé;)

---

Donc, pour résumer:

• la La vue snapshot non-UCM est unique et permet une consultation/débogage rapide d'une ligne de base plus ancienne à la fois.
• Pour les correctifs (modification de la source), vous créez un flux parallèle correctement nommé, avec la référence de base correcte, puis une vue UCM. Vous pouvez non seulement déboguer mais aussi corriger certains bogues dans une activité, la livrer cette activité au flux Int principal si ce bogue doit être rétro-ajusté sur un flux supérieur.
  (note: tous les bugs ne doivent pas toujours être livrés: ils peuvent être obsolètes par rapport à l'état actuel du développement)

Answer 2

Eh bien, cela dépend. En fait, la réponse réside dans la configuration de votre configuration pour pointer vers les fichiers appropriés. Votre configuration config indique à votre vue les versions des éléments à regarder. Mais la façon dont vous l'écrivez dépend de l'approche de votre projet par rapport aux lignes de base. Avez-vous appliqué une étiquette pour marquer cette ligne de base? Si oui, et si vous voulez seulement lire et pas commander quelque chose de nouveau, vos spécifications de configuration peut être aussi simple que

element * <LABELNAME> 

Si vous n'avez pas utilisé les étiquettes, vous pouvez également configurer vos spécifications de configuration pour vous montrer fichiers basés sur des dates. Plus les règles à ajouter pour contraindre vos choix d'éléments sont compliquées, plus cela devient compliqué. Si vous avez plus de détails, je peux essayer d'élaborer sur les règles dont vous pourriez avoir besoin. Sinon, je lirais les manuels fournis avec ClearCase. Si vous affichez l'aide étendue à partir de l'Explorateur ClearCase, puis que vous effectuez «Affichage des manuels Rational ClearCase en ligne», il devrait vous donner des liens vers les références de commande. C'est là que je vais quand j'ai besoin de modifier ma configuration de configuration d'une manière nouvelle. Notez également que nous n'utilisons que des vues dynamiques. Je ne sais donc pas si les vues instantanées fonctionnent différemment.

Answer 3

La façon dont je l'ai résolu ce problème en faisant un autre flux, un enfant Flux du flux d'intégration. La façon la plus simple de créer ce Stream consiste à ouvrir l'Explorateur de projets ClearCase (et non l'Explorateur Rational ClearCase) et à accéder au Projet, puis au Stream en question. Cliquez avec le bouton droit sur le flux d'intégration et sélectionnez "Créer un flux enfant ..."

Cliquez sur "Options avancées" et sélectionnez une référence pour chaque composant. Pour ce faire, sélectionnez le composant, puis sélectionnez "Modifier ..." et sélectionnez la référence spécifique que vous voulez voir. Vous voulez probablement sélectionner "Demander moi pour créer une vue pour ce flux". Sélectionnez "OK".

Tout développeur peut le faire. Vous n'avez pas besoin d'être un propriétaire VOB ou un propriétaire de projet ou de flux.