Comment faire pour passer git à ClearCase?

Question

J'ai récemment utilisé git svn et l'ai beaucoup apprécié. Maintenant, je commence un nouveau projet chez un client différent. ClearCase est le choix privilégié sur ce site. Je n'ai pas trouvé d'équivalent cuit de git svn pour ClearCase. Quelqu'un a-t-il déjà essayé d'utiliser git localement en tant que serveur frontal de ClearCase en utilisant des astuces, une configuration ou des scripts avec le moindre succès? Si oui pouvez-vous s'il vous plaît expliquer la méthode utilisée?

Answer 1

Voici une méthode qui évite détourne, que notre équipe a utilisé cette méthode avec succès depuis plus d'un an, jusqu'à ce que nous nous sommes retirés, ClearCase pour Subversion (par la politique de l'entreprise, même si c'est une étape en arrière pour notre équipe - nous avons été fondamentalement juste à l'aide de ClearCase comme un idiot système de fichiers, et pratiquement le travail en mode natif dans git, mais nous sommes maintenant à l'aide de git-svn pont qui n'est pas aussi beau que natif git.)

Nous avons utilisé deux répertoires, un pour le ClearCase instantané et maître repo git, qui nous avons partagé au sein de l'ensemble de l'équipe et de ne jamais les fichiers édités, et pour notre "travail" de répertoire.

La préparation de la ClearCase vue instantanée est:

% git init
% git add **/*.cxx **/*.h **/Makefile (et ainsi de suite)
% git commit -m "initial"

Puis clone dans votre répertoire de travail:

% mkdir ~/travail
% git clone /chemin/vers/repo

Travail dans le répertoire de travail, sur une branche:

% git checkout -b
% ...modifier/compiler...
% git add -u
% git commit

Assurez-vous que le ClearCase instantané est à jour avec des vierges (dont il a toujours été pour nous, parce que nous l'avons partagée au sein de l'équipe, et nous avons tous utilisé git).

La fusion de la direction sur le maître par la relocalisation, pour éviter automatique de fusion s'engager:

% git checkout master
% git pull
% git checkout fonctionnalité
% git rebase maître
% git checkout master
% git merge fonctionnalité
% git branch-d fonction

% git diff --nom-statut origin/master

Préparer la ClearCase vue en vérifiant/mkelem/rmname tout changé/nouveaux/les fichiers supprimés, en fonction de la sortie de l' git diff --name-status. Nous avons utilisé un roulé à la main de script pour ce faire. N'oubliez pas de consulter les répertoires qui ont ajouté/supprimé des fichiers:

Ensuite, poussez le git trucs de retour, et vérifier avec ClearCase:

% git push
% cd /chemin/vers/repo
% git reset --hard
% cleartool ci cleartool lsco -r -court -moi"

Il semble que beaucoup de commandes, mais cela comprend l'installation, et votre flux de travail quotidien ne pas utiliser de nombreuses commandes. Vous pouvez trivialement créer un script autour du push-back-to-ClearCase étape, et découvrir/montrer à votre équipe toute la fraîcheur supplémentaire git choses peu à peu comme tout le monde s'habitue à la base de flux de travail.

La vraie beauté de ce système est que, après un certain temps, quand tout le monde est compétent avec git, vous pouvez trivialement fossé ClearCase et de tous les associés individuels singe de travail et de frais. Peut-être donner à la société ClearCase gars qui avait besoin de vacances et de certains de recyclage avec les économies réalisées. (Malheureusement à mon entreprise le git des trucs a tous skunkworks, et nous avons déménagé à la Subversion vers l'avant de l'ClearCase, mais à l'envers à partir de git!)

J'ai fortement vous recommandons d'utiliser l' pristine script de ClearCase à l'échelle Mondiale, Git en local, qui s'exécute dans le ClearCase vue instantané et s'assure qu'elle et git sont synchronisés. Nous avons mis cela en place une tâche cron qui a couru deux fois par jour, et aussi couru manuellement à chaque fois que nous étions sur le point de pousser vers git. Malheureusement, le lien vers le blog n'est plus valide. Cependant, le script est toujours disponible sur Github.

Answer 2

Alors il ne peut pas être sans un peu de verrues (vous êtes prévenus), je sens que je dois mentionner que j'ai écrit un pont de toutes sortes.

http://github.com/charleso/git-cc

De transition entre les deux systèmes n'est pas facile, et je souhaite que ma solution était que la moitié aussi bon que git-svn. Une grande limitation est que vous êtes vraiment confiné à un miroir d'un seul flux; git-cc ne peut pas dupliquer tous vos Clearcase branches (aussi beau que ce serait). Toutefois, étant donné que la plupart des autres scripts de résoudre autour d'un seul Clearcase vue, vous n'êtes pire (OMI).

Personnellement, je trouve l'histoire assez important et quelles sont les autres solutions qui lui manque c'est de leur importation de l'histoire dans le dépôt Git. Être en mesure d'exécuter git-le blâme sur les fichiers et voir leurs véritables auteurs est très utile de temps en temps.

Si rien d'autre git-cc peut gérer ladite git log --nom-statut' étape de Matt solution ci-dessus.

Je suis curieux d'entendre ce que VonC et Matt (et d'autres) pense à cela, car je suis d'accord que tout pont à Clearcase se heurte à des difficultés et peut-être plus d'ennuis que cela vaut la peine.

Answer 3

Le processus j'ai l'habitude de suivre est la suivante:

• instantané de cd à l'intérieur d'un ClearCase view/vobs/myComponent
• git init .

Qui me permet d'envisager un ClearCase composant comme un repo Git.
Je peux alors faire toutes les branches et "privé" n'engage que je veux dans ce repo, rendant le fichier accessible en écriture que j'ai besoin d'eux (ce qui est possible au sein d'un instantané de la vue).

Une fois que j'ai un stable finale s'engager, je mettre à jour mon cliché, qui liste tous les "détourné" fichier: je checkout de contrôle et dans leur retour à ClearCase.

Compte tenu de la Git limites, les pensions de titres par ClearCase (UCM) est la composante de la bonne taille pour un repo Git.
Voir aussi Quelles sont les clearcase concepts chaque développeur devrait savoir? pour une comparaison entre ClearCase et Git.

L'idée reste la même:

• pas de git-cc
• pas besoin d'importer tous l'histoire de ClearCase (qui n'a aucune notion de référentiel de base, à la différence de la SVN révisions)
• création d'un repo Git dans un ClearCase vue pour l'intermédiaire s'engage
• final Git commit en miroir dans le ClearCase par le biais d'un archivage de tous les fichiers modifiés.