Hello, Un grand merci pour le taf, Julien, et pour le mail très complet.
Pour ce que je peux en dire, quelques éléments qui comptent à mes yeux : - rester autonomes par rapport aux plate-formes / conserver une version sur nos serveurs - n'avoir qu'un lieu pour les pull-request Sinon je suis ok pour passer à git, avec une préférence pour bitbucket, qui permet d'avoir des dépôts privés. Le 3 mai 2015 13:25, Nicolas <[email protected]> a écrit : > Merci Julien. > Quelques remarques : > - si le problème est de conserver les "bons" hash pour ceux ayant forkés > par rapport à ce que tu as fait en 2013, je pense qu'on peut s'en passer. > Il y a 7 forks et on les connait tous ! :-) > - j'utilise quotidiennement git-remote-hg mais je ne sais pas si les hash > sont bien conservés et s'il fonctionne de manière itérative. En revanche je > l'utilise pour commiter sur bitbucket/dotclear sans aucun soucis. > > Nicolas > > Le 3 mai 2015 13:11, Julien Wajsberg <[email protected]> a écrit : > > > Salut ! > > > > Comme promis à de nombreuses reprises, j'ai repris la conversion de > > mercurial vers git. > > > > j'avais déjà fait un premier essai en 2013 qui se trouve là: > > https://github.com/dotclear/dotclear > > > > Voici quels étaient mes buts: > > > > * ne pas péter le dépôt git existant qui a quelques forks. > > * permettre les imports itératifs (pour mettre à jour facilement). > > * que ce soit répétable par n'importe qui. > > * qu'on retrouve toutes les branches. > > > > > > Voici pour commencer quelques informations importantes sur git pour bien > > comprendre la suite. Je simplifie un peu donc si certains lecteurs sont > > bien versés dans git, ne m'en veuillez pas. > > > > * format des auteurs: Mercurial n'a pas de contrainte même s'il > recommande > > le format "Auteur <email>". En revanche git force ce format. > > > > * référence d'un commit (ça va être plus long) > > Dans git, un commit est identifié de manière unique par son "commit > hash", > > une suite de chiffres hexadécimaux. Ce qu'il faut savoir, c'est que ce > > "commit hash" est réellement un "hash" issu de différentes informations, > > notamment: son ou ses parent(s) (le(s) commit(s) sur lequel ce nouveau > > commit est basé), son contenu (y compris l'auteur donc). > > > > En pratique, pour nous, ça signifie que si l'une de ces informations > > change, le hash change... ainsi que tous ses "enfants", puisque, > > rappelez-vous, leurs "hashes" respectifs sont basés sur le "hash" de leur > > parent. Bref. > > > > Quelle est l'implication, me dites-vous ? Simple: si d'autres personnes > ont > > basé des changements sur un commit hash qui change... les changements > > doivent être "portés" vers le nouveau. Et si on ne connait pas si bien > que > > ça git, c'est un peu pénible pour trouver les bonnes commandes (notamment > > les bons hashes de base, etc, je rentre pas dans les détails). > > > > * les merges: c'est tout simplement un commit avec 2 parents. (papa ou > > maman, on s'en fout). > > > > > > Voici les différents moyens pour convertir de hg vers git: > > > > * le plus simple: github permet de convertir depuis un dépôt mercurial. > > J'ai vérifié: ça marche bien depuis le dépôt sur bitbucket. En revanche > je > > ne crois pas que ce soit répétable. > > Par ailleurs le dépôt obtenu a des différences par rapport au dépôt > > existant (la première différence est un commit de "Frank" converti en > > "Frank <Frank@localhost>" par github et "Frank <devnull@localhost>" par > > mon > > outil précédent. Et donc... et oui, des hashes différents à partir de ce > > commit. > > > > * fast-export: https://github.com/frej/fast-export/ > > C'est de loin le plus rapide. Il existe aussi des outils un peu plus > > simples d'utilisation qui l'utilisent (je crois que c'est Kevin qui en > > avait partagé un récemment). Je suis à peu près sûr que c'est celui que > > j'avais utilisé en 2013. > > > > Guide sommaire d'utilisation: > > > > hg clone https://hg.dotclear.org/dotclear dotclear-hg > > mkdir dotclear-git && cd gotclear-git && git init > > hg-fast-export.sh -r ../dotclear-hg --force > > > > Le problème est qu'en faisant cette manip j'obtiens encore des hashes > > différents à partir d'un commit de merge... il semble que l'ancienne > > version de fast-export que j'avais utilisée n'avait pas utilisé le même > > ordre pour les parents, et que ça suffise pour changer les hashes. À > noter > > que l'ordre utilisé par la version courante de l'outil ressemble plus à > ce > > qu'on ferait "à la main", donc a ma préférence. > > > > Il utilise des fichiers de mapping qu'il ajoute dans le répertoire .git > (et > > qui ne sont donc pas commités... et que j'ai donc perdus depuis mon essai > > de 2013 ;) ). > > > > * hg-git: http://hg-git.github.io/ > > Assez lent, et je n'ai pas réussi à récupérer toutes les branches. Mais > je > > n'ai pas insisté énormément encore. > > Il consiste à "pusher" et "fetcher" directement dans git depuis un dépôt > > mercurial. Ça semble marcher tant localement que à distance. Et semble > > prévu pour fonctionner de manière itérative. > > > > * git-remote-hg: https://github.com/felipec/git-remote-hg > > Non encore essayé. C'est le pendant du précédent: il permet de "pusher" > et > > "fetcher" directement dans hg depuis git. Il a un mode de compatibilité > > avec l'outil précédent également. Il est prévu pour fonctionner de > manière > > itérative. > > Je crois (non vérifié) qu'il fonctionne avec un dépôt local caché (si le > > dépôt spécifié est distant). > > > > * Outils de Mozilla: > > https://wiki.mozilla.org/ReleaseEngineering/VCSSync/HowTo > > Assez complexe car historiquement Mozilla a plusieurs dépôts distants > pour > > ses différentes branches (c'était ainsi que fonctionnaient les anciennes > > versions de Mercurial). Et du coup l'outil doit prendre ça en compte > alors > > que nous on s'en fout. > > Pas encore essayé. Mais il a l'avantage non négligeable d'être maintenu > et > > utilisé en production tous les jours. > > > > > > Voilà en gros où j'en suis. J'ai pas mal poussé l'outil "fast-export" > déjà, > > j'aimerais bien pousser mieux les autres avant de décider de l'outil, > pour > > les raisons de permanence du "hash" dont j'ai parlé plus haut. > > > > > > NOTE: si on décide de tout passer sur git une bonne fois pour toutes, et > > abandonner mercurial une bonne fois pour toutes, le problème devient > > immensément plus simple. > > > > On pourrait alors utiliser l'outil de github pour convertir, puis > > l'importer sur bitbucket et/ou https://git.framasoft.org/. Une fois > qu'on > > a > > du git partout c'est trivial de synchroniser des dépôts ensemble (et > > d'ailleurs celui de framasoft a un outil pour le faire automatiquement). > > Voir > > > > > http://framablog.org/2015/03/13/google-code-ferme-ses-portes-nous-on-les-ouvre/ > > pour le dépôt de framasoft. > > > > Si on est prêt à le faire, ce serait la solution que je préconiserais par > > simplicité + utiliser le dépôt de framasoft parce qu'on aime bien ce > qu'ils > > font, et c'est du libre. > > > > Avoir une présence sur github me semble nécessaire car c'est là que tout > se > > passe aujourd'hui, mais on ne pourrait n'y avoir qu'une présence en > miroir. > > > > Bon dimanche ! > > -- > > Julien > > -- > > Dev mailing list - [email protected] - > > http://ml.dotclear.org/listinfo/dev > > > -- > Dev mailing list - [email protected] - > http://ml.dotclear.org/listinfo/dev > -- Anne / Kozlika -- Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
