2010-03-19 6 views
12

Je travaille actuellement sur ClearCase et migre maintenant vers GIT. Mais nous avons besoin de cette migration pour que tout le travail soit fait dans GIT et les données seront synchronisées avec le flux ClearCase. Nous aurons les mêmes noms de branches et de noms de flux dans GIT et CC, donc les scripts ne devraient pas poser de problème. Le problème ici est,Sync GIT et ClearCase

Quelqu'un peut-il suggérer ce qui est le meilleur modèle pour la synchronisation CC et GIT

  1. Demandez à tous les vobs en CC comme repo unique GIT, et ont le courant principal dans CC que divers branches dans GIT. - Repo simple GIT (VOBS) et plusieurs branches (flux CC). - Cela prend moins de place car les VOB sont conservés en tant que dépôt unique avec de nombreuses branches.

  2. Avoir des branches CC importantes en tant que référentiels GIT indépendants et chaque référentiel ayant tous les VOB CC. - Beaucoup de repo GIT pour de nombreuses branches CC - Cela prendra beaucoup d'espace car les VOB seront répliquées.

qui pensez-vous est la meilleure façon de le synchroniser avec ClearCase

Répondre

4

Ayez toutes les vobs en CC comme repo unique GIT, et ont le courant principal dans CC que diverses branches dans GIT

Non et oui

ont d'importantes branches de CC comme dépôts GIT indépendants et chaque dépôt ayant tous les CC VOBs

Non et non

En relisant my answer about Git limits, vous ne devriez pas essayer de "tout" dans un dépôt Git. Voir également "What are the basic clearcase concepts every developer should know?" pour une comparaison entre ClearCase et Git.

Le flux peut être importé en toute sécurité en tant que branche.
Mais les VOB ne sont pas nécessairement un Git Repo.

Si vous utilisez UCM, je recommanderais un repo Git par composant UCM.

Quoi qu'il en soit, vous devez enregistrer dans votre Git Repo un moyen de connaître la vue ClearCase à utiliser pour synchroniser (via un simple clearfsimport) vos données.
La vue utilisée pour cette réimportation de données ClearCase sera une vue UCM automatiquement associée au flux de droite, pour le bon VOB.


Note: je mentionne dans « How to bridge git to ClearCase? » une solution plus simple, mais qui n'importe pas toute l'histoire dans une pension Git.

+1

Merci, cela semble m'aider beaucoup. Je suis d'accord que le fait d'avoir tous les VOB ou tous les composants UCM dans un seul repo fera que le GIT prendra beaucoup de temps pour effectuer l'opération surtout si c'est comme 20 gb. pouvez-vous me préciser sur plus de chose. Supposons que je dispose d'un repo pour un composant ucm/un VOB, mais selon la discussion, j'ai tous les flux CC/UCM importants comme branches dans le repo, est-il possible pour différents développeurs de pousser simultanément vers différentes branches du même repo sans avoir attendre si toutes les branches sont dans le même repo nu? –

+0

@Senthil: oui: vous pouvez pousser n'importe quelle branche dans un repo nu à distance. Remarque: si vous avez besoin de plusieurs composants UCM (c'est-à-dire plusieurs dépôts Git) pour travailler (soit en les lisant, soit en les modifiant), vous aurez besoin d'un ou plusieurs projets principaux avec sous-modules (voir http://stackoverflow.com/questions/1979167/ git-submodule-update/1979194 # 1979194) – VonC

1

En ce qui concerne les branches et les prises en pension, je vais avec un vob == d'une règle de git, car git est vraiment destiné être utilisé par un seul projet, de la même manière que pour les vobs. En ce qui concerne les branches, les noms de branche à travers vobs/repos doivent correspondre. Jetez un oeil à sous-modules dans git pour voir si cela peut être utilisé dans votre cas. Ce que je voudrais voir personnellement, c'est un backend git-cc mature, qui me permettra d'utiliser git sur ma dev-box, tout en étant capable de me synchroniser avec le repository CC que je suis obligé d'utiliser.

4

Bien que je ne suggère pas nécessairement que c'est la meilleure façon de synchroniser les deux, vous pouvez importer l'historique et repasser les modifications à Clearcase via mon outil git-cc, comme indiqué here.