Comment faire pour passer de git à ClearCase?

j'ai récemment utilisé git svn et l'a beaucoup apprécié. Maintenant, je commence un nouveau projet à un autre client. Sur ce site, la SCM de choix est ClearCase. Je n'ai pas trouvé d'équivalent de git svn pour ClearCase. Y a-t-il quelqu'un qui a essayé d'utiliser git localement comme un front-end pour ClearCase en utilisant quelques astuces, une configuration ou un script avec une certaine mesure de succès? Si oui, pouvez-vous expliquer la méthode utilisée?

40
demandé sur Bas Bossink 2010-02-26 17:08:34

3 réponses

Voici une méthode qui évite les détournements, que notre équipe a utilisée avec beaucoup de succès pendant plus d'un an, jusqu'à ce que nous retirions ClearCase pour Subversion (Politique de L'entreprise, bien que ce soit un pas en arrière pour notre équipe - nous utilisions simplement ClearCase comme un système de fichiers muet, et fonctionnions virtuellement nativement en git, mais maintenant nous utilisons le pont git-svn qui n'est pas aussi agréable que natif git.)

nous avons utilisé deux répertoires, un pour le snapshot ClearCase et le master git repo, que nous avons partagé avec toute l'équipe et dans lequel nous n'avons jamais édité de fichiers, et un pour notre répertoire "working".

la préparation dans la vue snapshot ClearCase est:

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% git commit -m "initial"

puis clonez dans votre répertoire de travail:

% mkdir ~/work
% git clone /path/to/repo

travail dans l'Annuaire de travail, sur une branche:

% git checkout -b feature
% ...edit/compile...
% git add -u
% git commit

assurez-vous que le snapshot ClearCase est à jour avec vierge (qu'il a toujours été pour nous, parce que nous l'avons partagée au sein de l'équipe, et nous avons tous utilisé git).

puis fusionner la branche sur le master en la rebasant, pour éviter une commit de fusion automatique:

% git checkout master
% git pull
% git checkout feature
% git rebase master
% git checkout master
% git merge feature
% git branch -d feature

% git diff --name-status origin/master

préparer la vue ClearCase en vérifiant/mkelem/rmname tout fichier modifié / nouveau / supprimé, après la sortie de git diff --name-status . Nous avons utilisé un script roulé à la main pour le faire. N'oubliez pas de vérifier tous les répertoires qui ont ajouté ou supprimé des fichiers:

puis repousse les trucs git, et vérifie avec ClearCase:

% git push
% cd /path/to/repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

il semble que beaucoup de commandes, mais cela inclut la configuration, et votre flux de travail quotidien n'utilise pas beaucoup de commandes. Vous pouvez trivialement construire un script autour de l'étape push-back-to-ClearCase, et découvrir/montrer à votre équipe tous les trucs cool supplémentaires git peu à peu que tout le monde s'habitue au flux de travail de base.

la vraie beauté de ce système est, après un certain temps quand tout le monde est compétent avec git, vous pouvez trivialement jeter ClearCase et tous les travaux de singe individuels et les frais associés. Peut-être donner au gars de ClearCase de la compagnie des vacances bien méritées et un peu de recyclage avec les économies. (Malheureusement, dans mon entreprise, les trucs de git étaient tous des skunkworks, et nous sommes passés à Subversion-forwards à partir de ClearCase mais en arrière à partir de git!)

I fortement je vous recommande d'utiliser le script pristine de ClearCase Globally, Git Locally , qui s'exécute dans la vue snapshot ClearCase et assure sa synchronisation avec git. Nous avons mis cela en place comme un travail de cron qui a fonctionné deux fois par jour, et a également exécuté manuellement chaque fois que nous étions sur le point de pousser de nouveau à git. Malheureusement, le lien vers le blog n'est plus valide. Cependant le script est toujours disponible sur GitHub .

35
répondu Matt Curtis 2012-10-23 10:04:27

bien que ce ne soit pas sans quelques verrues (vous avez été avertis), je pense que je devrais mentionner que j'ai écrit une sorte de pont.

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

faire le pont entre les deux systèmes n'est pas facile, et j'aimerais que ma solution soit aussi bonne que git-svn. Une grande limite est que vous êtes vraiment limité à reproduire un seul flux; git-cc ne peut pas cloner toutes vos branches Clearcase (aussi agréable que cela serait être.) Cependant, étant donné que la plupart des scripts alternatifs se résolvent autour d'une seule vue Clearcase, vous n'êtes pas dans une situation pire (IMO).

personnellement, je trouve l'histoire très importante et ce qui manque d'autres solutions est leur importation de l'histoire dans Git. Être capable d'exécuter git-blâmer sur les dossiers et voir leurs auteurs réels est très utile de temps en temps.

si rien d'autre git-cc ne peut gérer l'étape susmentionnée "git log --name-status" dans la solution de Matt ci-dessus.

je suis certainement curieux d'entendre ce que VonC et Matt (et d'autres) pensent de cela, car je suis d'accord que n'importe quel pont à Clearcase est chargé de difficultés et peut être plus de problèmes que ce qu'il vaut.

12
répondu charleso 2010-03-19 21:18:00

le seul processus que je suis habituellement est:

  • instantané cd dans un ClearCase view/vobs/myComponent
  • gitinit .

qui me permet de considérer un composant ClearCase comme un git repo.

Je peux alors faire toutes les ramifications et les commits" privés " que je veux dans cette repo, rendant le fichier accessible en écriture comme j'en ai besoin (possible dans une vue d'instantané).

une fois que j'ai stable final commit, je mets à jour ma vue de snapshot, qui liste tous les fichiers "détournés": je les vérifie et les revérifie à ClearCase.

compte tenu des git limits , un composant repo per ClearCase (UCM) est la bonne taille pour un repo Git.

Voir aussi Quels sont les concepts clearcase de base que chaque développeur devrait connaître? pour une comparaison entre ClearCase et Git.

le l'idée reste la même:

  • pas de git-cc
  • pas besoin d'importer tout l'histoire de ClearCase (qui n'a aucune notion de baseline de dépôt, contrairement aux révisions SVN)
  • création d'un git repo dans une vue de casse pour les commits intermédiaires
  • final git commit mirrored dans la vue ClearCase à travers une checkin de tous les fichiers modifiés.
5
répondu VonC 2017-05-23 12:17:34