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-... 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 - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

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.

Hello, C'est un des sujets qui a été évoqué en Bretagne ? On migre vers git ? -- Bruno

Quel est l'intérêt d'avoir tout une infrastructure sur les serveurs dotclear ? Un des gros gros avantages d'utiliser github c'est que les sauvegardes, la maintenance, la correction des bugs, les mises à jour tout est fait par github. Et à comparer entre github et bitbucket concernant git il n'y a vraiment pas photos. bitbucket est à la traîne de plusieurs années pour essayer d'implémenter la même chose : exemple très parlant la gestion des pull request. Et si le seul avantage c'est d'avoir des dépôts privés, il suffit de craquer un p'tit billet. Après on peut aussi jouer sur gitlab mais pas la même visibilité. Le 3 mai 2015 16:49, mirovinben <forum(a)mirovinben.com&gt; a écrit : > Hello > > Je ne sais pas pour les autres ceusses qui, comme moi, n'ont pu faire la > colo du Guilvinec ("Guilvinec" ? marrant, le dico de Thunderbird me propose > "guillotine" à la place) mais j'aimerais assez savoir ce qui s'y est passé > (un album photos, c'est possible ?) et, surtout ce qui s'est dit au sujet > de Dotclear. > > Bisous, > Michel > > > Le 03/05/2015 16:18, Bruno a écrit : > >> Hello, >> >> C'est un des sujets qui a été évoqué en Bretagne ? On migre vers git ? >> >> -- >> Bruno >> > > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Bon, je crois que je vais m'installer un Gitlab chez moi, histoire de voir comment la migration hg -> git se fait… Le 4 mai 2015 07:27, Kozlika <kozlika(a)gmail.com&gt; a écrit : > Eric Van der Vlist s'est déjà collé au passage de Trac vers Gitlab. Si un > sorcier a envie de passer quelques nuits là-dessus :-) > http://eric.van-der-vlist.com/blog/2013/11/06/from-trac-to-gitlab/ > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 4 mai 2015 08:04, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : > Et pourtant > des concurrents ont une interface plus sympa pour ça. > Ah bon ? Je veux bien des exemples, même un seul ! :-)

Euh, non, être sur Github n'a absolument rien apporté de neuf. Tous les PR là-bas ont été fait par des gens qui étaient déjà dans le périmètre de DC, aucune tête nouvelle. Donc non, je ne suis absolument pas convaincu par l'attrait de Github. De plus si un dev sait faire un PR sur Github, il saura probablement faire de même sur Bitbucket, c'est un peu pareil. Bref, pour moi le sujet n'est pas Github ou Bitbucket, mais hg ou git. Le 4 mai 2015 08:04, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : > … > * sur "Quant à la visibilité, faut pas rêver, c'est pas une présence > (noyée > parmi > les autres) chez Github qui va nous rapporter des contributeurs, le miroir > qu'on a eu là-bas pendant un temps l'a démontré en 2012", je dirai juste > qu'on a eu des pull requests non sollicités alors qu'on a fait zéro pub. > :) > > AMA c'est pas tant la visibilité que le côté "frictions". Il faut > l'avouer: > tout développeur a aujourd'hui un compte github et sait faire une pull > request dessus. C'est là que se trouve l'intérêt indéniable. Et pourtant > des concurrents ont une interface plus sympa pour ça. > > -- > Julien >

On peut résumer ? 1. Est-ce qu'on a un outil pour synchroniser régulièrement le dépôt hg ( dotclear.org) vers le dépôt Git (Github)

2. Est-ce qu'on souhaite tout basculer de hg à git

3. Est-ce qu'on ne devrait pas commencer par versionner un projet annexe (genre la refonte des sites) en git sur un dépôt git installé chez Dotclear (éventuellement interfacé avec un Gitlab) ? Et ensuite seulement basculer le reste ?

Sachant tout de même qu'il faut songer à la maintenance de tout ça, et que si on est une demi-douzaine à discuter aujourd'hui, on ne sera plus qu'un ou deux à s'en préoccuper dans 1 mois (comme pour le dev de dotclear).

Bon, je crois que je vais m'installer un Gitlab chez moi, histoire de voir comment la migration hg -> git se fait…

Vu le bordel qu'il installe, je vais peut-être faire un peu plus propre qu'un simple apt-get. Je suis en train de voir (virtualenv, rbenv, …) Le 4 mai 2015 08:05, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > Le 4 mai 2015 07:56, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > > > Bon, je crois que je vais m'installer un Gitlab chez moi, histoire de > voir > > comment la migration hg -> git se fait… > > > > apt-get install gitlab > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck

Le 4 mai 2015 07:56, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Bon, je crois que je vais m'installer un Gitlab chez moi, histoire de voir > comment la migration hg -> git se fait… > apt-get install gitlab

Et hop, après une install (qui foire parce que j'avais Apache déjà installé) et qu'il utilise nginx (du coup ça conflicte), un gros nettoyage et restage sous Bitbucket en ce qui me concerne. Si on install gitlab quelque part, va falloir être prudent moi je dis…

Le 4 mai 2015 11:25, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Wokey, en plus l'uninstall m'a foutu le souk côté python. Bref, à ne > SURTOUT pas installer en dehors d'une VM (ou avec virtualenv). > > Le 4 mai 2015 11:24, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > >> Et hop, après une install (qui foire parce que j'avais Apache déjà >> installé) et qu'il utilise nginx (du coup ça conflicte), un gros nettoyage >> et restage sous Bitbucket en ce qui me concerne. >> >> Si on install gitlab quelque part, va falloir être prudent moi je dis… Use docker, luke :) http://www.damagehead.com/docker-gitlab/ -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 3 mai 2015 17:21, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Cela dit, que ça ne vous empêche pas de devancer l'appel, hein ? :-) > Qui a les clés ? Noé ? Je parle du rib pour pouvoir faire un virement. -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Bonjour, Juste une remarque par rapport a Bitbucket et la possibilité de faire des dépôts privés. Pourquoi ne pas utiliser GitLab dans ce cas : https://about.gitlab.com/ ? En effet, dans ce cas on aurait pas à se préoccuper de la survie de tel ou tel prestataire, des possibilités offertes par les un ou les autres. Z'en pensez quoi ? Mathieu Le 03/05/2015 15:21, Kozlika a écrit : > 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 <nikrou77(a)gmail.com&gt; 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 <felash(a)gmail.com&gt; 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-... >> >>> 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 - Dev(a)list.dotclear.org - >>> http://ml.dotclear.org/listinfo/dev >>> >>> -- >> Dev mailing list - Dev(a)list.dotclear.org - >> http://ml.dotclear.org/listinfo/dev >> >> > > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 3 mai 2015 16:35, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > C'est une solution en effet, mais il va falloir penser à transférer tout ce > qu'il y a actuellement sur le Trac (tickets, …). Il semble exister des scripts de migration trac-> gitlab. Ca vaut peut-être le coup de faire un POC ? -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

2015-05-03 13:25 GMT+02:00 Nicolas <nikrou77(a)gmail.com&gt;: > 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 ! :-) > Je ne l'ai pas mis dans mon mail original, mais j'en avais déjà fait le deuil :) Ceci dit il faut pas que ça se reproduise une fois qu'on fait un miroir de manière officielle... > - 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. > Ce sera un de mes prochains tests :) J'ai surtout peur pour la rapidité et la gestion de la synchro de toutes les branches. -- Julien -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

2015-05-04 10:05 GMT+02:00 Franck Paul <carnet.franck.paul(a)gmail.com&gt;: > Philippe et Julien, ce n'est pas parce que le dépôt officiel sera chez > Framasoft que ça changerait quoi que ce soit. Ce ne sont pas eux qui vont > gérer les PR, les tickets, etc… De ce point de vue, ça ne change rien. > tout à fait ! > > Loin de moi l'idée de renier Framasoft, c'est chez eux que j'ai découvert > Dotclear, c'est dire, mais je ne crois pas que ce soit la bonne question, > ni d'ailleurs la question originale (qui date de quelques années > maintenant) : comment synchroniser — j'ai pas dit migrer ! — le dépôt > officiel hg chez nous sur le dépôt miroir chez Github ? > En effet, ce n'était pas la question originale, juste une question alternative (en note en fin de mon mail, note). J'ai toujours la question originale dans le pipe -- juste après mes qq heures d'essai je me suis dit que si on décidait de tout passer sur git tout était plus simple, donc autant poser la question. Vu que c'est pas d'actualité, je garde la question originale, pas de souci. > > Maintenant question audience, Framagit est loin d'atteindre celle de Github > ou de Bitbucket, du coup à part l'image Frama*, quel avantage réel ? > Framasoft gère la synchro vers github pour toi (suffit de leur envoyer un mail -- je présume qu'ils sauront faire vers bitbucket aussi). Tout en utilisant du logiciel open source plutôt que le logiciel proprio de github. On a donc les intérêts suivants: * quelqu'un fait l'admin à ta place. * on est présent sur github. * on est présent sur bitbucket. D'où ma proposition. Encore une fois, moi je m'en fous, c'est vous qui choisissez. Ça me dérange pas du tout de rester sur du bitbucket + hébergement maison. De toute manière c'est pas moi qui fais donc c'est pas moi qui décide. > > Julien, concernant le "volume" de data à synchroniser, je crois que ce > n'est pas vraiment un souci vu la quantité de trafic existant sur les > dépôts actuels et les rares branches qui sont encore en activité (la > default/master, la 2.7, et quelques branches spécifiques qui bougent très > rarement). > > On synchronise régulièrement le dépôt DC vers le dépôt Hg, et ça ne prend > que quelques minutes, je ne vois pas pourquoi ça enflerait. > Ce n'est pas ça le souci; synchroniser du hg avec du hg, heureusement que ça va vite. Comme du git vers du git. C'est la conversion hg -> git qui prend du temps. Avec le premier outil ça va vraiment vite, avec le second ça va vraiment lentement (et en plus a priori la gestion des branches est galère -- mais je maitrise pas trop mercurial non plus). Notre volume reste effectivement léger, il n'empêche qu'il y a un historique :) -- Julien -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Pour moi, le vrai souci c'est la permanence des commentaires des pull requests et des issues, c'est ça qui est difficile (ou impossible ?) à bouger. Donc à vous de voir si cette permanence-là vous est utile sur le long terme. 2015-05-04 11:52 GMT+02:00 Franck Paul <carnet.franck.paul(a)gmail.com&gt;: > Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt maître > à quelqu'un d'autre que Dotclear ? > > Sinon ok pour le temps de process hg -> git, je n'avais pas compris que > c'était là qu'il pouvait y avoir plus de job que d'ordinaire. > > Le 4 mai 2015 11:48, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : > > > 2015-05-04 10:05 GMT+02:00 Franck Paul <carnet.franck.paul(a)gmail.com&gt;: > > > > > Philippe et Julien, ce n'est pas parce que le dépôt officiel sera chez > > > Framasoft que ça changerait quoi que ce soit. Ce ne sont pas eux qui > vont > > > gérer les PR, les tickets, etc… De ce point de vue, ça ne change rien. > > > > > > > tout à fait ! > > > > > > > > > > > > Loin de moi l'idée de renier Framasoft, c'est chez eux que j'ai > découvert > > > Dotclear, c'est dire, mais je ne crois pas que ce soit la bonne > question, > > > ni d'ailleurs la question originale (qui date de quelques années > > > maintenant) : comment synchroniser — j'ai pas dit migrer ! — le dépôt > > > officiel hg chez nous sur le dépôt miroir chez Github ? > > > > > > > En effet, ce n'était pas la question originale, juste une question > > alternative (en note en fin de mon mail, note). > > J'ai toujours la question originale dans le pipe -- juste après mes qq > > heures d'essai je me suis dit que si on décidait de tout passer sur git > > tout était plus simple, donc autant poser la question. > > Vu que c'est pas d'actualité, je garde la question originale, pas de > souci. > > > > > > > > > > > > Maintenant question audience, Framagit est loin d'atteindre celle de > > Github > > > ou de Bitbucket, du coup à part l'image Frama*, quel avantage réel ? > > > > > > > > > Framasoft gère la synchro vers github pour toi (suffit de leur envoyer un > > mail -- je présume qu'ils sauront faire vers bitbucket aussi). Tout en > > utilisant du logiciel open source plutôt que le logiciel proprio de > github. > > On a donc les intérêts suivants: > > > > * quelqu'un fait l'admin à ta place. > > * on est présent sur github. > > * on est présent sur bitbucket. > > > > D'où ma proposition. Encore une fois, moi je m'en fous, c'est vous qui > > choisissez. Ça me dérange pas du tout de rester sur du bitbucket + > > hébergement maison. De toute manière c'est pas moi qui fais donc c'est > pas > > moi qui décide. > > > > > > > > > > > > Julien, concernant le "volume" de data à synchroniser, je crois que ce > > > n'est pas vraiment un souci vu la quantité de trafic existant sur les > > > dépôts actuels et les rares branches qui sont encore en activité (la > > > default/master, la 2.7, et quelques branches spécifiques qui bougent > très > > > rarement). > > > > > > On synchronise régulièrement le dépôt DC vers le dépôt Hg, et ça ne > prend > > > que quelques minutes, je ne vois pas pourquoi ça enflerait. > > > > > > > Ce n'est pas ça le souci; synchroniser du hg avec du hg, heureusement que > > ça va vite. Comme du git vers du git. > > C'est la conversion hg -> git qui prend du temps. Avec le premier outil > ça > > va vraiment vite, avec le second ça va vraiment lentement (et en plus a > > priori la gestion des branches est galère -- mais je maitrise pas trop > > mercurial non plus). > > > > Notre volume reste effectivement léger, il n'empêche qu'il y a un > > historique :) > > > > -- > > Julien > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 4 mai 2015 11:52, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt maître > à quelqu'un d'autre que Dotclear ? > On n'est plus avec subversion. Si github (ou ...) meurt ou change de politique, on s'en va. Ce qui milite dans le choix d'un hébergeur git/hg externe c'est la maintenance. On a peu de bras donc on ne peut pas se goinfrer avec toute la tablette de chocolat ! -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt maître à quelqu'un d'autre que Dotclear ?

Tout ça à cause d'une tortue derrière une fenêtre, j'vous jure, quelle énergie perdue ! PS : je vous fait une explication de texte si nécessaire ;-) Le 4 mai 2015 14:25, Kozlika <kozlika(a)gmail.com&gt; a écrit : > Le 4 mai 2015 11:52, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > > > Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt > maître > > à quelqu'un d'autre que Dotclear ? > > > > > Non, moi aussi ça me gêne, mais j'ai été geek-élevée par Oliver alors ceci > explique peut être cela ;-) > > > -- > Anne / Kozlika > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Bonjour Otir, Petite histoire : on a choisi hg (Mercurial) (et du coup Bitbucket) à l'époque plutôt que Git (et Github) simplement parce que le client Tortoise sous Windows fonctionnait bien pour hg et qu'il n'y avait rien d'aussi facile à utiliser côté git. Tortoise : tortue Windows : fenêtre Voili, voilà. Tout le reste c'est du blabla :-D Le 4 mai 2015 15:02, Laurence Furic <immalo(a)gmail.com&gt; a écrit : > Au quarante-huitième message dans ma inbox une explication de texte me > semble bienvenue effectivement. > :-) > Amitiés à tous > Otir > > 2015-05-04 9:00 GMT-04:00 Franck Paul <carnet.franck.paul(a)gmail.com&gt;: > > > Tout ça à cause d'une tortue derrière une fenêtre, j'vous jure, quelle > > énergie perdue ! > > > > PS : je vous fait une explication de texte si nécessaire ;-) > > > > Le 4 mai 2015 14:25, Kozlika <kozlika(a)gmail.com&gt; a écrit : > > > > > Le 4 mai 2015 11:52, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit > > : > > > > > > > Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt > > > maître > > > > à quelqu'un d'autre que Dotclear ? > > > > > > > > > > > > > Non, moi aussi ça me gêne, mais j'ai été geek-élevée par Oliver alors > > ceci > > > explique peut être cela ;-) > > > > > > > > > -- > > > Anne / Kozlika > > > -- > > > Dev mailing list - Dev(a)list.dotclear.org - > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > -- > > Franck > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > http://about.me/Otir > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Mais du coup si la visibilité sur github n'apporte rien pourquoi on n'enlève pas complètement le pseudo-miroir ? On reste sur bitbucket avec mercurial et picétou. Le 4 mai 2015 15:20, Laurence Furic <immalo(a)gmail.com&gt; a écrit : > Merci Franck! > (et pour le fun, les seuls mots que je vois traduits pour moi sont ceux de > la langue que je parle couramment of course) > Never mind! I can take blabla anytime anyways. > Love > Otir > > 2015-05-04 9:16 GMT-04:00 Franck Paul <carnet.franck.paul(a)gmail.com&gt;: > > > Bonjour Otir, > > > > Petite histoire : on a choisi hg (Mercurial) (et du coup Bitbucket) à > > l'époque plutôt que Git (et Github) simplement parce que le client > Tortoise > > sous Windows fonctionnait bien pour hg et qu'il n'y avait rien d'aussi > > facile à utiliser côté git. > > > > Tortoise : tortue > > Windows : fenêtre > > > > Voili, voilà. > > > > Tout le reste c'est du blabla :-D > > > > Le 4 mai 2015 15:02, Laurence Furic <immalo(a)gmail.com&gt; a écrit : > > > > > Au quarante-huitième message dans ma inbox une explication de texte me > > > semble bienvenue effectivement. > > > :-) > > > Amitiés à tous > > > Otir > > > > > > 2015-05-04 9:00 GMT-04:00 Franck Paul <carnet.franck.paul(a)gmail.com >: > > > > > > > Tout ça à cause d'une tortue derrière une fenêtre, j'vous jure, > quelle > > > > énergie perdue ! > > > > > > > > PS : je vous fait une explication de texte si nécessaire ;-) > > > > > > > > Le 4 mai 2015 14:25, Kozlika <kozlika(a)gmail.com&gt; a écrit : > > > > > > > > > Le 4 mai 2015 11:52, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > > > écrit > > > > : > > > > > > > > > > > Y'a vraiment que moi que ça gêne de laisser les clés de notre > dépôt > > > > > maître > > > > > > à quelqu'un d'autre que Dotclear ? > > > > > > > > > > > > > > > > > > > > > Non, moi aussi ça me gêne, mais j'ai été geek-élevée par Oliver > alors > > > > ceci > > > > > explique peut être cela ;-) > > > > > > > > > > > > > > > -- > > > > > Anne / Kozlika > > > > > -- > > > > > Dev mailing list - Dev(a)list.dotclear.org - > > > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > > > > > > > > > > > -- > > > > Franck > > > > -- > > > > Dev mailing list - Dev(a)list.dotclear.org - > > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > > > > > > -- > > > http://about.me/Otir > > > -- > > > Dev mailing list - Dev(a)list.dotclear.org - > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > -- > > Franck > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > http://about.me/Otir > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 4 mai 2015 15:35, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > picétou ? C'est un nouveau candidat face à hg et git ? Ué, c'est un fork du cpold, un concept prometteur de gestion de versions : https://github.com/malko/cpold -- Bruno -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 4 mai 2015 11:52, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Y'a vraiment que moi que ça gêne de laisser les clés de notre dépôt maître > à quelqu'un d'autre que Dotclear ? > Non, moi aussi ça me gêne, mais j'ai été geek-élevée par Oliver alors ceci explique peut être cela ;-)

Mais Bon ! Trac ! N'importe quoi qui fait le boulot sera de toute manière plus agréable. kallithea, fait git et hg