rex - passage de cvs à git

REX - Passage de CVS à GitPierre Templier

@ptemplier

Ippon Technologies © 2015

Sommaire

● Contexte● Migration technique● Choix workflow(s) de travail● Accompagnement et mise en oeuvre● Bilan : problèmes et bénéfices

CVS


Contexte

● Client utilisant CVS au sein d'une petite équipe : ~10 personnes.

● Volonté de changer pour quelque chose de plus récent.

● 2 solutions envisagées : SVN et Git

○ Client d'abord tenté par SVN car peu de changement dans l'utilisation par

rapport à CVS.

○ Mais un projet a été réalisé par une société externe sur un repo privé

GitHub, le choix de Git s'est donc fait sur la facilité de récupérer l'historique

de ce projet.


Migration technique (1)● Utilisation de cvs2svn qui dispose d’un module cvs2git : http://cvs2svn.tigris.

org/cvs2git.html

● Besoin d’accéder physiquement à une copie du repo CVS

● Fichier de config permettant

○ De transcoder les utilisateurs (trigramme => “Prénom Nom” + Email)

○ D’exclure des fichiers/dossiers inutiles

■ ‘target' ou ‘src/webapp/WEB-INF/lib’

● En sortie, 2 fichiers au format fast-import

○ git --bare init .

○ cat git-{blob,dump}.dat | git fast-import

http://cvs2svn.tigris.org/cvs2git.html




Migration technique (2)● 4 repositories CVS

○ ~200 projets

○ Chaque repo CVS contient beaucoup de projets qui

n'ont rien à voir entre eux

● 1 répertoire du repo CVS deviendra un repository Git

● Création d'un script bash pour automatiser les exports

vers des repositories Git

● Avant la migration on verrouille en écriture chaque

repository CVS

○ touch writers


Utilisation● Repositories exposés via GitBlit

○ Webapp java

○ Gestion des Droits

○ Recherche

○ Navigation dans le code

○ Statistiques

○ Historique des commits


Impact hors développement● Faibles impacts sur l’usine logicielle

● Changement de l’url scm dans le pom : utilisé par le plugin maven release

● Ajout du plugin Git dans Jenkins

● Création d’un utilisateur Jenkins dans Gitblit et renseignement des

credentials dans le settings.xml maven utilisé par jenkins


Workflows utilisés

CentraliséFeature Branches

Gitflow


Configuration commune

// renseignements sur l'utilisateur présents dans les commits

git config --global user.name "John Doe" git config --global user.email [email protected]// sauts de lignes Linux dans les sources

git config --global core.autocrlf true// pull --rebase par défaut pour éviter de polluer l'historique

git config --global branch.master.rebase truegit config --global branch.autosetuprebase always// stocke le mdp en clair pour ne pas le retaper

git config --global credential.helper store

Utilisation de rebase lors des pull

http://user.name/


Mise en oeuvre● Volonté de l'équipe d'utiliser le client graphique Git intégré à Eclipse

● Habitude de fonctionner avec le client CVS d’Eclipse

● Habitude de rester dans l’IDE pour les interactions SCM

● Migration des projets un par un plutôt que tout d'un coup

● Formation initiale sur le poste du développeur

● Différentes zones de travail : Workspace, Index, Repository Local, Repository Distant

● Les commandes à connaître : clone, commit, push, pull, stash, reset

● Explication du paramétrage pull --rebase

● Savoir où on en est : `git status` / vue historique Eclipse

● Incitation à créer des branches dès que le besoin s’en fait sentir (feature branch)

● Puis aide au fur et à mesure des besoins/problèmes.

● Dans l'équipe 2 autres personnes avaient déjà travaillé avec git, cela a facilité la monté en compétence car plusieurs

personnes pouvaient aider.

● Pas de modification de commits déjà publiés (i.e. pas de push --force )

● Interdit au niveau de Gitblit


Problèmes - Eclipse ● Impossible de comparer un fichier lors d'un merge

● Présente des fichiers comme modifiés alors qu'il ne sont pas modifiés

○ info différente de git status

● Impossible de comprendre ce que fait le "mark as merged"

● Résoudre un conflit en faisant add n'est pas intuitif sous eclipse

○ git status nous donne directement cette information

● Lorsqu'un push échoue, message d’échec que l'on prend pour un succès

● Obligation de jongler entre les vues Eclipse

○ Vue Projet

○ Vue Git Repositories

○ Vue Historique

○ Vue Staging


Problèmes - Habitudes● Volonté de récupérer uniquement les changements sur certains fichiers

● plutôt que tous ceux ramenés par un pull

● Pull implique de commiter ou stasher ses changements au préalable

● Tendance à garder 1 projet par branche dans son workspace

● 1 branche sur master

● 1 branche sur develop

● Nouveau vocabulaire, nouveaux concepts

● Commit a un sens différent en CVS et en Git

● Stash est une pile si on sauve plusieurs fois ses fichiers temporaires ils ne sont plus sur le dessus de

la pile et 'git stash pop' ne les ramène pas


Leçons tirées● Il ne faut pas sous estimer le travail d'accompagnement pour passer à Git et oublier ses habitudes

CVS. Il est important que personne ne reste bloqué à cause de l’outil, il faut donc qu’il y ait toujours

une personne capable de dépanner sur Git.

● Mieux vaut passer petit à petit les projets sous Git : cela permet de monter sereinement en

compétence sur Git et d'abord sur des petits projets

● Le client en ligne de commande donne souvent des informations plus pertinentes qu'Eclipse et est plus

prédictible

● Changement d’habitude dans le workflow de travail : commits réguliers en local puis push après revue

de ces commits, le fait d’avoir 2 étapes permet plus de vérification et de réorganiser ses commits avant

de pusher (squash ou rebase interactif).


BénéficesCe qu’en tirent les développeurs

○ Un certain confort à travailler en local (plus de commits régulièrement)

○ Une préparation plus fine des commits avant de les publier

○ Un facilité à travailler sur des branches dès que le besoin s’en fait sentir

○ Renommages de fichiers bien suivis

○ Commits comme un ensemble cohérent de changements sur différents fichiers

○ Historique complet notamment lors du merge de branche (pas d’info sur les branches mergées en CVS)

○ Graphe historique/branches permet de bien se repérer dans les sources

○ Rapidité générale du système

○ Facilité de report d’un hotfix via cherry-pick

Dans le futur

On pourrait envisager d’utiliser des workflow de type Pull Request, notamment à des fins de code review systématisé

Questions ?

Contact : @ptemplier

rex - passage de cvs à git

Technology