J'ai demandé il ya quelques jours how to commit an arbitrary directory tree in ClearCase et la réponse que j'ai reçue était d'utiliser l'outil clearfsimport. Cela a fonctionné parfaitement jusqu'à présent et peut « importer » dans ClearCase (sur une vue dynamique) des arborescences arbitraires (de certains répertoires du système de fichiers externe):comment effectuer une mise à jour sur un arbre de répertoire arbitraire
clearfsimport -recu -nset /some/external/directory/foo .
Mon flux de travail est que je fais tout mon travail et tester dans ce répertoire externe (foo) et quand je suis heureux, je confie mes sources à ClearCase en utilisant l'outil clearfsimport comme décrit ci-dessus. Cela a fonctionné jusqu'ici dans le commit initial mais maintenant je me trouve vouloir importer les sources modifiées. Effectivement j'ai besoin d'importer, à la place du répertoire foo existant, une nouvelle arborescence de répertoires. Les changements peuvent être omniprésents: fichiers/répertoires ajoutés, supprimés ou renommés, fichiers modifiés en répertoires ou liens symboliques (et vice versa). Effectivement, nous pouvons parler de deux arbres de répertoires très différents avec une sortie diff -r très verbeuse.
Je prévois d'utiliser le flux de travail suivant:
ct co .
ct rm foo // remove existing dir from view
ct ci .
clearfsimport -recu -nset /some/external/directory/foo . // import the new dir version
Voyez-vous des problèmes avec l'approche ci-dessus en termes d'histoire, etc?
Pour la divulgation complète Je maintiens mon projet (en /some/external/directory) en utilisant git et ainsi créer un « propre » copie de mon projet avant d'exécuter clearfsimport (suppression de fichiers spécifiques à git comme .git, .gitignore etc.). J'ai généralement une histoire plus détaillée dans git mais je ne suis intéressé que par le maintien de l'historique de «jalons» spécifiques dans ClearCase pour les autres membres de l'équipe qui voudront peut-être regarder mon code et son évolution au fil du temps. Cela étant dit, je ne veux pas (pour l'instant au moins) utiliser des outils pour rapprocher git à ClearCase et préférer garder les choses simples.
Je précise que le flux de travail que j'essaie d'établir est à sens unique (répertoire externe vers ClearCase) et que j'importe dans une vue dynamique.
regardant la page de manuel pour clearfsimport Je vois quelque chose comme « deux passes » étant mentionné et options comme -rmname qui me font chose qu'il est possible de faire fonctionner juste clearfsimport la cible étant une structure de répertoire existant (sans avoir d'abord ct rm). Mais je ne suis pas sûr quelle incantation utiliser exactement et si cela traiterait des cas où un nom donné a changé de diverses façons (par exemple de fichier en répertoire ou de répertoire en lien symbolique ou de lien symbolique en fichier) ou comment les renames sont traitées en termes de histoire.
Je suis un peu mal à l'aise que 'clearfsimport' fera la bonne chose en ce qui concerne les noms dont le type a changé (par exemple du fichier au lien symbolique ou du lien symbolique au répertoire), c'est pourquoi je pensais que 'ct rm' donnerait une table rase. Mais je comprends votre réponse à dire juste faire confiance 'clearfsimport' pour faire la bonne chose ... –
@MarcusJuniusBrutus Je suis d'accord, ce besoin d'être imbriqué pour les cas de bord, mais en général,' clearfsimport' est fait pour ce cas d'utilisation . – VonC
@MarcusJuniusBrutus Le problème avec rm est que vous perdez complètement l'historique de tous les fichiers communs qui ont été modifiés. ClearCase les verra comme de nouveaux éléments sans historique. – VonC