Contrôle de version Clearcase Vs Git
Nous utilisons multisite clearcase repository, et nous avons souvent besoin de fusionner et de construire notre système. Cette fusion et cette réplication prennent presque trois jours pour être disponibles sur tous les sites. Par conséquent, pour être plus efficaces, nous prévoyons de passer à Git contrôle de version. Pourriez-vous indiquer les inconvénients potentiels que nous pourrions rencontrer si nous passions à Git à partir de Clearcase?
@ zzz777: Votre question a été posée dans une perspective tellement centrée sur ClearCase qu'elle n'a pas été compréhensible pour les personnes qui n'avaient jamais utilisé ClearCase auparavant. En fait, Git est à des années-lumière de ClearCase, ce sont les systèmes SCM commerciaux qui ont besoin de rattraper les systèmes OSS.
J'ai de l'expérience avec ClearCase et git et je peux vous dire que la fonctionnalité de recherche/fusion de ClearCase est le résultat de sa conception (fondamentalement cassée) basée sur des fichiers de gestion des versions, mais vous n'avez pas besoin d'un outil aussi primitif. pour fusionner avec votre branche privée la branche partagée. ClearCase est orienté fichier, et checkin-s est basé sur les fichiers, c’est pourquoi vous avez besoin de l’utilitaire de recherche (fichiers), mais git est basé sur la validation, et c’est le bon modèle, car vous résolvez un problème ou implémentez une fonctionnalité , l’ensemble des modifications ou aucune d’elles sont les seules options qui ont un sens.
Git a une fonctionnalité de fusion très puissante qui fait le bon choix. Il y a deux façons de faire ce que vous demandez (mettre à jour votre branche privée pour qu'elle soit la branche partagée + vos modifications).
Le plus évident est de faire une fusion. Ainsi, dans votre branche privée, vous ne faites que:
git merge sharedbranch
ensuite, s’il existe des conflits (en réalité beaucoup plus rares que dans ClearCase), résolvez-les et
git commit
Et c'est tout. De plus, comme git a toute l’histoire locale, vous n’aurez pas à perdre d’innombrables heures. Si vous avez beaucoup de fichiers, comme dans ClearCase, la fusion est extrêmement rapide, au moment où ClearCase effectue une fusion de 10 fichiers, git finira probablement de fusionner 100 fichiers facilement.
Utiliser git merge signifie que vous conservez l’historique et si votre historique ressemblait à ceci avant la fusion:
o---1---2---3 (sharedbranch)
\
a---b---c (privatebranch)
après la fusion, cela ressemblera à ceci:
o---1---2---3 (sharedbranch)
\ \
a---b---c---m (privatebranch)
Cela préserve l’historique de vos modifications et permet aux autres utilisateurs de revoir votre travail.
Et rappelez-vous, ce ne sont PAS des historiques de révision de fichier, mais des fichiers d'archives, si l'historique d'arborescence est l'unique historique qu'il est judicieux de stocker, même si les branches ne diffèrent que de 1 ou 2 fichiers, l'état que vous souhaitez conserver est l'arborescence, pas une seule. fichier.
La deuxième option consiste à utiliser rebase, ce qui signifie que vous donnez l'impression que toutes vos modifications ont été effectuées à partir du dernier code de la branche partagée.
La commande que vous utilisez (encore une fois, sur la branche privée):
git rebase sharedbranch
L'arborescence de l'historique changera de:
o---1---2---3 (sharedbranch)
\
a---b---c (privatebranch)
à
o---1---2---3 (sharedbranch)
\
a'--b'--c' (privatebranch)
Donc, si vous laissez un peu de temps à git pour le comprendre et l'utiliser un peu, vous verrez à quel point le modèle git est meilleur et combien le modèle ClearCase est cassé.
BTW, le problème des jumeaux maléfiques dans ClearCase n’existe tout simplement pas dans git car git ne suit pas les répertoires (croyez-moi, vous n’avez PAS besoin de ça).
De plus, si vous avez déjà eu une spécification de configuration un peu plus compliquée avec plusieurs branches et que vous avez migré des fichiers d'une branche à l'autre, vous savez probablement à quel point l'ordre des règles dans la spécification de configuration est important et frustrant. voir les anciennes versions des fichiers car la spécification de configuration est "incorrecte". Cela se produit dans ClearCase en raison de sa conception de base et, il va sans dire, ce genre de merde ne peut pas arriver dans git.
Donc, pour conclure, git n’a pas d’outil primitif tel que "trouver la fusion" car il n’en a pas besoin. Il a un modèle supérieur et un modèle de fusion supérieur qui fonctionne réellement. Il est ultra rapide par rapport à ClearCase (vue statique CCRC ou vue dynamique, vous le nommez).
Le seul endroit où ClearCase pourrait avoir un Edge est la mise à jour instantanée de la vue dynamique, mais cela est également atténué par le fait que vous pouvez taper plus rapidement git checkout branch que vous ne pouvez mettre à jour la spécification de configuration.
Problèmes rencontrés dans un bureau professionnel mixte:
- Histoire Mutable.
Vous pouvez faire des choses vraiment stupides (et puissantes) avec GIT. Cela peut causer une perte de source. - Fusion automatique.
C'est la meilleure fonctionnalité de git. MAIS, nous avons dû interrompre le développement pendant une semaine pour trouver le code source manquant. MSVS a un problème heureux avec le changement aléatoire des fins de ligne. Si vous ne retirez pas régulièrement du référentiel, cela devient confus et les modifications sont perdues. - Commande Push/Pull.
Clearcase gère la commande de date et l’historique pour vous, mais git les ignore. - Mise en scène.
Clearcase (au moins UCM) gère les promotions de branche et d’autres choses pour vous. Git ne le fait pas. Vous devrez gérer cela avec soin. - $ ID $
N'existe pas pour git. Le suivi des versions à partir des versions réelles et les problèmes de recherche de la version du fichier source devront être traités manuellement. (Je ne suis pas sûr de votre processus de publication).
Pour votre dernier référentiel de code, je pourrais suggérer un référentiel de versions, soit un autre système de contrôle de code source, soit un référentiel git distinct, géré et acceptant uniquement les extractions.
J'utilise actuellement git pour mon projet solo et tout va bien. Mais, dans une maison de mixité avec une variété d'éditeurs, je ferais attention. Vous pouvez vraiment vous fâcher du pied sans savoir avec Git.
Je n'ai pas utilisé non plus, hg ou bzr. Il serait peut-être intéressant d’examiner ces problèmes au fur et à mesure que certains des problèmes disparaissent et qu’ils présentent des fonctionnalités permettant d’atténuer certains des problèmes susmentionnés.
J'espère que ça aide.
J'ai travaillé avec Git et ClearCase et une fois que vous apprenez à utiliser Git puis à effectuer le changement, vous ne regarderez plus jamais en arrière. Assurez-vous que vous avez le temps de former vos développeurs - cela devrait être votre priorité absolue. Git est une approche totalement différente de SCM par rapport à ClearCase.
Quelques points à considérer (inconvénients possibles):
- Vous aurez besoin d’un maître true pour le dépôt, et non pas de quelqu'un pour surveiller la source, mais de quelqu'un qui comprend vraiment le fonctionnement du GDS (pas seulement ce qu’une interface graphique leur affiche) et peut gérer votre modèle de branchement (voir n ° 2). )
- Adopter/développer un modèle de branche robuste. Un bon exemple, et que j’ai utilisé, est http://nvie.com/posts/a-successful-git-branching-model/
- Vous allez devoir passer beaucoup de temps à aider vos développeurs à réapprendre tout ce qu'ils pensaient savoir sur l'utilisation/l'interaction avec SCM.
Si vous pouvez surmonter les trois précédents, il y aura très peu d'inconvénients (le n ° 3 étant le plus difficile.) En ce qui concerne @PAntoine, la plupart de ces problèmes sont liés à la formation - le n ° 1 nécessiterait une décision vraiment médiocre pour perdre le code source. . git reflog vous donnera accès à chaque commit sur le référentiel. Le seul moyen de détruire la source serait d'utiliser git reflog expire --expire=whatever refs/heads/master, git fsck --unreachable, git Prune et git gc, qui ne devraient être gérés que par le référant principal. Il existe également le problème universel d'un développeur qui ne commet pas sa source (D'oh!)
Comme je l'ai mentionné dans " Quels sont les concepts de base de ClearCase que tout développeur doit connaître? ", ClearCase pourrait avoir certaines fonctionnalités "décentralisées" avec ses mises en pension multi-sites, mais il s'agit toujours d'un CVCS:
il a un lien fort avec l'ID utilisateur du système (ce qui n'est pas pertinent dans un DVCS, où il n'y a pas de référentiel utilisateur unique).
il dispose d'un référentiel unique pour la gestion des noms d'étiquette et de branche (admin vob), tandis que vous pouvez définir une branche "test" dans 15 dépôts Git différents sans problème (sauf que vous devez savoir ce que signifie
repo1/test, par rapport àrepos2/test).il centralise également une définition de flux de travail de fusion dans la hiérarchie de flux (UCM) (vous pouvez visualiser où vous êtes censé fusionner un travail d'un flux à un autre).
il propose via UCM une définition du sous-ensemble de codes (composant), avec gestion de la dépendance. Git n'a que des sous-modules, sans mécanisme de détection surchargé/surchargé.
il gère tout type de fichiers, même les fichiers binaires volumineux, alors qu'un DVCS (tout type de DVCS) est préférable pour gérer uniquement le code source.
En fin de compte (dans notre migration de ClearCase vers Git), cela implique un certain nombre de refactorisations/réorganisations du code source afin de disposer de référentiels Git gérables.
Avez-vous besoin d'un outil pour vous aider avec votre gestion de configuration logicielle (SCM) ou votre système de contrôle de version (VCS)?
C'est ce à quoi la discussion ClearCase vs Git se résume.
Pour ainsi dire, vous comparez des pommes à des oranges.
Considérer ClearCase comme juste un autre VCS est une vue étroite de ce que ClearCase est; restez fidèle à ClearCase si votre objectif est d’exporter le bon produit dans votre magasin.
D'un autre côté, Git est probablement le meilleur VCS sur le marché à ce jour (bien qu'il ne propose aucun support SCM). Vous pouvez donc y basculer si votre problème est la création de branches et la fusion ... sont le résultat d’une ligne de base mal définie et de vues mal configurées) ... La réplication VOB est nulle - je vous le donne.
L'inconvénient de votre déménagement prévu est que vous allez jeter votre support outillage SCM. Et vous devrez faire face à une multitude d'autres outils et à beaucoup de travail manuel pour obtenir ce que vous aviez avec ClearCase.
Quoi qu’il en soit, un bon VCS est l’épine dorsale de tout système de gestion de la chaîne logistique. Votre transfert à Git pourrait donc être rentable à long terme.