plop journal !
Aujourd'hui, je viens te parler d'un sujet ... intéressant je trouve, même si certains aspects on déjà pu être traités en partie ici (et je sais que c'est un sujet qui intéresse du monde)
Jusqu'à présent, dans la boite où je suis (et dans mes projets perso ou non) les codes écrits sont toujours placés dans un repository subversion.
D'ailleurs, ça n'a pas coupé au repository multi projet, mal (pas) géré, grossissant, etc
Désormais, et suite à des changements (améliorations) de méthodes de dev, et aussi par apprentissage de techniques diverses, je regarde pour migrer vers des systèmes plus évolués, non initialement orientés décentralisation mais surtout orienté gestion de merge, branches, etc.
J'ai donc commencé à regarder git, bazaar et mercurial
Git est très intéressant je trouve, j'aime beaucoup la gestion des branches, l'interface utilisateur mais a été éliminé à cause du support windows et eclipse (nécessaire dans ma boite)
Dommage...
Je me suis ensuite tourné vers Mercurial mais j'ai été déçu. Le support eclipse n'est pas terrible, et les fonctionnalités de base m'ont parues moins sympa. La gestion des fichiers (renomage, ajout, etc) est moins bien faite, plus proche de subversion je trouve.
J'avais éliminé précédemment bazaar pour je ne sais plus quelle raison, mais je me suis repanché dessus récemment.
Tout d'abord les points intéressants :
Les fonctionnalités de base ont l'air bien faites, gestion des fichiers, interface avec l'utilisateur. c'est un peu moins bien que git je trouve, mais ça roule.
L'un des points qui m'a vraiment plus est qu'en fait il est assez maléable au niveau de la gestion des working copies, des branches, etc (Shared repository)
Il est aussi très maléable quant aux workflows utilisables
Le support eclipse / windows a aussi l'air pas mal, résultat c'est assez bien parti
L'un des problèmes que j'ai provient du fait que justement il est malléable. Résultat, pour mettre en place un système utilisable, c'est pas évident tellement les solutions sont nombreuses.
Qu'utilisez vous en général ?
Système alasvn ? (un dossier par branche)
Système alagit ? (un dossier central dans lequel on switch de branche)
Un autre système ?
Mais maintenant que je pense faire mon choix, le problème de la migration s'impose.
Mais la franchement, comment on migre un dépot de source ?
J'ai essayé plusieurs techniques, et en général ... ben ça échoue tôt ou tard...
En y ajoutant la rapidité (sic) de bazaar ...
J'ai testé svn2bzr mais planté au bout de quelques heures.
L'un des problèmes que j'ai eu provient en partie des exports depuis svn peu efficaces (en utilisant svndumpfilter)
J'ai ensuite voulu jouer avec BzrFastImport ... echec en provenance de svn
J'ai donc eu ensuite l'idée de passer par git
Un petit coup de git-svn et hop un répo git potable (facile sur ce coup là)
Un coup de git fast-export et j'ai mon dump correct.
Les tests que je réalise sont sur un projet légèrement conséquent mais pas énorme non plus.
Y'a de l'ordre de 3-400 000 lignes de codes, un dump de 1,3Go pour en gros 2-3 ans d'historique (à ne pas perdre évidemment)
Maintenant que le dump est là ... il faut l'importer
Et là c'est le drame...
Y'a pas à dire, lorsque Torvalds parle de rapidité dans sa vidéo sur git finalement c'est loin d'être négligeable.
L'import dans bazaar est d'une sous efficacité monstrueuse : ça prend 2Go de ram, 2Go de swap (ok 100% en fait...) et ça n'avance pas...
Comment faites vous pour gérez vos migrations de sources ?
Y'a-t-il d'autres outils intéressant où faut-il juste galérer ?
Quels sont vos expériences en la matière, surtout ?
Journal des migrations de systèmes de sources
14
août
2009
# Tu connais CVS =)
Posté par syj . Évalué à -2.
le plus gros projet sur lequel j ai bossé, on dépassait 1000 classe Java et plein de pages jsp.
vous etes combien de developpeur
[^] # Re: Tu connais CVS =)
Posté par CrEv (site web personnel) . Évalué à 3.
On est moins de 15 dev sur plusieurs projets en parallèle, mais le problème n'est pas vraiment sur la taille (la taille n'est qu'un facteur aggravant des migrations)
Le problème est qu'on doit gérer plusieurs branches de certains softs (une ou deux branches de dev centralisées, une a deux branches de maintenance plus des branches spécifiques à d'autres besoins)
Ben sans avoir de quoi faire un merge potable ... ça pue
Et là ben svn (ou cvs) c'est naze (voir mon précédent journal sur ce que j'en pense)
Mais ok, on peut surement faire avec. Mais surement pas aussi facilement, rapidement.
Faire une branche d'un soft (pour par exemple une adaptation spécifique pour un client) avec une mise à jour de cette branche par rapport à la mainline (qui n'est pas la branche de dev) mais également avec report de certaines choses faites dans la branche spécifique vers une branche elle de dev ... ben sans outils de merge suffisamment corrects c'est une perte de temps monstruseuse alors que c'est si simple avec les bons outils
D'ailleurs dans les "workflows" proposés par bazaar, l'un deux est en fait calqué sur cvs/svn donc développement centralisé, pas de branche (tout juste des commits locaux) mais tout de même une vrai gestion de branche.
Ha oui, j'oubliais, dans le modèle de dev que nous utilisons, certains branches sont à accès restreints. Tout le monde n'a pas les droits de commit sur les branches de maintenance, et ceux corrigeant les bugs ne l'ont pas forcément (l'intégration passe donc pas une autre personne). Pour ce genre de chose, de multiples branches, voir des branches perso publiques sont vraiment un plus.
[^] # N'élimines pas Mercurial si vite
Posté par Yannick Jost . Évalué à 7.
Le process migration est en cours, adaptation des workflows, réécriture des hooks, formation des utilisateurs, et improvisation face aux multiples use cases qu'on avait pas vu avant...
Pour l'instant je n'ai pas été déçu par l'outil et sa facilité à être customisé.
Je pense que nous allons beaucoup y gagner en souplesse de travail et le merge tracking sera infinement plus simple.
Qq chiffres pour te donner une idée :
- 25 000 commits
- 1 500 000 lignes de code
- 5 ans d'historique
- code cross-platform Linux/Windows
- Importé en 4-5 heures dans Mercurial (pas sur une bête de course).
[^] # Re: N'élimines pas Mercurial si vite
Posté par CrEv (site web personnel) . Évalué à 2.
Par contre il est vrai que dans les spécificités le dépot svn que j'ai ... est un merdier sans nom
Je crois d'ailleurs que c'est la dernière fois que je gère un même dépot pour plusieurs projets (quelque soit le système)
Tu l'as importé avec quoi ?
Autant git-svn fonctionne bien, autant le même dépot attaqué avec Hg j'ai pas réussi :-(
Donc pour le moment je pense passé par l'export git
Il me reste donc juste à faire git -> bzr
Tiens au fait, comment faites vous (si vous l'utiliser) avec les svn:externals ? J'en ai toute une tripoté dans mon répo...
# Mercurial
Posté par ribwund . Évalué à 3.
Je suis curieux, tu peux expliciter ? En général les gens trouvent que la proximité avec les commandes de svn facilite la vie (pas besoin de chercher 5 minutes comment faire un truc).
Ou alors t'es super fan de l'index de git ? Mais dans ce cas on ne le retrouve pas non plus dans bzr.
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 1.
ben voui, mais uniquement dans le cas où c'est une bonne chose.
C'est pas parce que svn le fait qu'il faut le faire. d'ailleurs c'est bien comme ça que svn existe : "cvs le fait" ;)
En fait, surtout avec des utilisateurs ne connaissant que les gui pour svn je préfère largement avoir un fonctionnement totalement différent et des commandes différentes mais que ce soit mieux et plus performant.
> Ou alors t'es super fan de l'index de git ? Mais dans ce cas on ne le retrouve pas non plus dans bzr
Merdouille, j'avais pas fait gaffe :(
voui, cet index est _vraiment_ une fonctionnalité intéressante !
Je ne compte même plus où certains dev viennent me voir car ils ont copié / renomé / déplacé des fichiers sans passer par svn. Et lorsque le gars tente de commiter après 1 semaine de dev à tout changer ... ben c'est la merde (même si c'est une connerie en soit)
Faudrait ptetre que je vois si c'est possible d'écrire un plugin pour le gérer
(j'ai commencé à écrire quelques plugins, en partie pour masquer les urls et les faire façon launchpad : bzr push id:~user/project/branch d'ailleurs qqn sait dans launchpad ce que veut dire les + ?)
Je vais voir si je peux améliorer ce point.
[^] # Re: Mercurial
Posté par ribwund . Évalué à 5.
Sinon t'as toujours pas expliqué quelles commandes posent problème, et j'en vois un paquet d'autres où hg est clairement plus simple, par exemple:
hg revert .par rapport à
git reset --hard ORIG_HEAD.[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
Par contre, le --similarity est sympa, mais le fait de _devoir_ y passer un paramètre sensé indiqué le degré de ressemblance me gène.
Mais bon, c'est pas mal qd même
En fait, je pensais qu'un jour un système arriverait enfin à trouver ces changements sans problème et sans intervention manuelle. Je crois que git en est pas très loin, avec l'histoire d'index venant perturber un poil aussi. En gros, gérer le répo en une seule donnée et juste des index présentant le début / la fin des fichiers, un renommage de fichier ne devrait être vu que comme un changement d'index, et déplacer une portion de code entre deux fichiers devient également aisée (git le fait)
Donc en gros ce qui m'intéresse n'est pas tant l'index visible de git (qui oblige en fait à sélectionner ce qu'on commit, même si je gère toujours comme ça, y compris sous svn) mais la gestion données / ressources / fichiers qui est derrière.
Pour la deuxième partie du commentaire (et précédemment) :
En fait, la simplicité des commandes est souvent secondaire. Surtout que les alias permettent de simplifier toutes ses commandes.
Pour ce qui est des Hg, c'est pas une commande en particulier, mais plutôt l'ensemble, les choix par défauts (je sais ça va un peu à l'encontre de la phrase précédente) qui sont parfois opposés aux choix de git.
En fait j'aime bien le côté non basé sur les habitudes précédentes des svn/cvs/... de git
Je me fous totalement que ce soit proche ou loin de svn en fait.
Et des trucs manquent dans hg par défaut, comme les branches locales (dispo en extension)
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
En fait git ne fait *rien*. Il ne stocke aucune information sur le mouvement du code ou du fichier mais essaie de le découvrir lors d'un merge avec des heuristiques.
Le similarity, ça dépend des usages, si t'as l'habitude de faire des mv+edit (c'est pas vraiment une bonne idée), ou pas.
Pour les branches, oui c'est mieux d'utiliser les bookmarks, mais activer une extension c'est pas très compliqué non plus :)
J'avais trouvé cet article pas mal pour expliquer les différentes branches de hg:http://nubyonrails.com/articles/five-features-from-mercurial(...)
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
Ben en fait c'est surtout, je crois (mais me trompe peut-être), qu'il utilise aussi des snapshots pour stocker les modifs et non des changesets (bzr utilise aussi des snapshots, hg des changesets) ce qui doit simplifier un peu les choses.
Mais ce qui est bien, c'est surtout qu'il le fasse lui même.
Mais d'un autre côté, il est vrai que rien n'empêche de créer une sorte d'alias (avant status ou commit par exemple, histoire que ce soit fait correctement et presque automatiquement)
> si t'as l'habitude de faire des mv+edit (c'est pas vraiment une bonne idée)
Ben je dirais que ça dépend.
Si on prend un langage dans lequel les classes ont le nom du fichier, ou le namespace en fonction du répertoire parant, lorsqu'on renome un classe on va déplacer le fichier, ou inverssement.
Et dans ce cas j'aime bien que la modif dans son ensemble (déplacement, édition du fichier + édition des imports dans tous les autres fichiers concernés) soit fait en un commit, c'est plus propre je trouve. Maintenant c'est vrai que c'est peut-être aussi un relant de svn, puisque qu'avec les commits locaux on ne push que lorsque que c'est fini et on peut faire de très petits commits facilement.
Note : finalement j'ai réussi à importer mes projets avec ... bzr svn-import et 2 3 options
Très simple finalement (je sais pas ce que j'avais fait avant pour louper avec cet outil...)
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
Non, tu te trompes. Ils font tous pareils, ils stockent un snapshot de repo à un instant donné. Après, par défaut git n'optimise rien (il stocke une nouvelle copie de tous les fichiers modifiés), mais lorsqu'on repack il va construire un paquet de delta pour optimiser la taille.
Au contraire hg va directement construire des deltas (plus simples que ceux de git après repack) tout en faisant attention à limiter la taille totale: si la version de base + les deltas sont plus gros que deux fois le texte, alors il stocke une version entière, il peut donc toujours récuperer la version en O(taille du texte), la complexité est bornée !
Mais tout ça c'est des optimisations de format de stockage, en pratique on pourrait utiliser le format de git pour hg et vice-versa.
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
Etrange car d'après le document ici http://www.infoq.com/articles/dvcs-guide bzr et git stockent l'historique sous forme de snapshot et hg de changeset
A moins que ça ait changé depuis (le document date de 2007)
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
Disclaimer: je suis dev hg, et je connais bien le fonctionnement interne de git, et un peu celui de bzr, je suis plutôt certain de ce que je raconte ;)
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
bon ok, j'avais pas lu les commentaires.
En fait, l'un des points qui me gène le plus avec hg ... c'est le support eclipse :(
sans cela je l'aurais utilisé pour migrer je pense.
Mais lors de mes derniers tests, entre svn et eclipse, hg était moins bon que bzr
D'ailleurs, j'ai pas vraiment trouvé de réponse sur le net, est-il possible d'avoir un index comme dans git ? (obligeant de sélectionner ce qu'on commit) voir même en utilisant un plugin hein.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse
A part l'extension record, qui permet de choisir au commit ce qu'on veut mettre, il n'y a pas de truc "persistant" qui permettrait de dire "ça c'est pour le prochain commit". C'est pas un truc dur à faire, je pense que personne n'a trop eu le besoin (et la plupart des gens aiment pas trop comme approche, vu que ça fait committer des trucs pas testé).
Sinon y'a mq qui permet de faire ça et plein d'autres choses (principalement faire des séries de patchs propres), mais c'est pour les utilisateurs avancés.
Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)
Oui, c'est pour le plaisir.
D'abord, en 2005 quand git et hg ont été crée, hg était vraiment devant (git avait pas de repack et donc les repos prenaient quelques gigas, pas d'interface utilisateur, etc.), et c'est le moment où j'ai commencé à contribuer.
Git avait pas grand chose pour lui, sauf le fait d'être crée par Linus, mais bon hg était pas en reste, Matt étant une personne très intelligente (et également respecté dans la communauté du kernel).
Ensuite c'est en python, et donc, à mon avis, plus agréable. Y'a pas besoin de 50 lignes de code pour les trucs simples de l'interface utilisateur (qui ont pas besoin d'être rapide), ou pour les accès réseaux. En général le code est plus homogène: git s'est amélioré depuis, mais entre du C+python, et du C+sh+perl, j'avais trouvé mon camp ;)
Enfin bzr c'était juste un truc très très lent à l'époque, avec du python over-engineeré (du xml, etc.), donc j'ai jamais sérieusement considéré. D'ailleurs canonical a failli abandonné bzr pour hg à un moment tellement ils avaient du mal, ça n'a pas eu lieu pour des problèmes de licence (ils voulaient le pouvoir sur le copyright, pour launchpad qui était pas libre).
Et aussi, la communauté de mercurial est super sympa, les gens sont aimables sur irc et la mailing list, ça compte aussi quand on contribue à un projet.
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
merci, je ne connaissais pas
> et la plupart des gens aiment pas trop comme approche, vu que ça fait committer des trucs pas testé
spa faux, surtout avec des commits locaux qui sont plus petits, je verrai bien si je m'en sert finalement ou non
> Sinon y'a mq
ha oui, on m'en a déjà parlé mais j'ai pas encore utilisé
> c'est en python, et donc, à mon avis, plus agréable
/me aimerais plutôt du ruby mais bon... ;-)
> Enfin bzr c'était juste un truc très très lent à l'époque, avec du python over-engineeré (du xml, etc.), donc j'ai jamais sérieusement considéré
Ben après avoir joué quelques jours avec, je comprend pourquoi la première impression que j'avais eu était pas très flatteuse
Le problème c'est que même maintenant c'est très très lent encore :(
J'ai une config zsh où j'affiche dans le prompt des infos sur mes sources (dcvs utilisé, non de la branche, présence de modifs, add, etc)
sous git c'est immédiat
sous hg c'est pas mal du tout (en fait je dirais même aussi rapide que git ;-) )
sous bzr ... ben à chaque commande on attend au moins 1s pour avoir la main ... c'est ptetre rien mais très gonflant !
Bon, avec tout ça, tu m'a donné envie de laisser une nouvelle chance à hg.
J'ai donc réinstallé tout ça, je suis en train de tester mercurialeclipse aussi
Je crois qu'un des problèmes que j'avais eu était au niveau de la conversion svn -> hg mais vu que j'ai maintenant des dépôts git et bzr de mes projets je devrais bien arriver a faire une conversion.
Si tout se passe correctement, je pense que je vais finalement revoir mon jugement et retourner vers hg.
Git m'intéresse toujours, mais son mauvais support windows/eclipse fait que professionnellement je ne peux pas l'utiliser. Pour du perso c'est différent ;)
Bzr est quand même sympa, les fonctionnalités sont là, mais à l'usage ... beurk c'est lent. Mais si ça fait le taff c'est toujours mieux que svn
Par contre si Hg fait tout ce dont j'ai besoin, support bien windows (ça je crois que c'est bon) et eclipse (ça me semble pas mal, j'ai lu aussi que le plugin eclipse que je pensais utiliser pour bzr n'est en fait qu'un fork de celui de mercurial...) ça peut finalement être le grand gagnant
Bon, j'ai plus qu'à convertir mon dépôt pour tester pour de vrai (et je ferai ptetre un nourjal si j'arrive a des trucs sympa)
(merci pour la petite histoire du choix git, hg, bzr. J'avais déjà entendu des choses du genre, surtout pour bzr, a voir aussi maintenant que les 3 ont pas mal évolués)
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
Pour la conversion la méthode quasi-infaillible c'est git->hg, vu que les deux systèmes sont assez proches.
Have fun!
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
Pour le moment j'ai fait un test avec hg convert + les chemins vers mes trunk/tags/branches et à priori ça a marché correctement.
Le truc c'est que mon répo n'est pas hyper propre (et nettoyer un répo svn c'est ... dur !) donc ça facilite pas la vie des outils, mais pour le moment c'est ok.
Vais ptetre quand même essayer aussi git->hg, au moins pour savoir
[^] # Re: Mercurial
Posté par CrEv (site web personnel) . Évalué à 2.
Tu utilises quoi pour faire des branches locales (si tu en fait) ?
J'ai regardé localbranch mais je trouve que ça ne marche pas très bien (en tout cas dans mon cas c'était étrange, on dirait que lorsque je suis revenu dans ma branche locale "default" les modifs faites dans la branche locale étaient toujours là)
Utilises-tu mq pour ça ?
[^] # Re: Mercurial
Posté par ribwund . Évalué à 2.
Sinon des clones locaux c'est pas mal non plus, et c'est simple (et ça prend pas trop de place vu que ça utilise des hardlinks).
# git svn
Posté par laurent laffont (site web personnel) . Évalué à 2.
[^] # Re: git svn
Posté par CrEv (site web personnel) . Évalué à 1.
- support windows bof
- support eclipse nul
- impossibilité de faire du merge de branches distantes (faut faire un rebase)
donc finalement je souhaiterais utiliser un système full dcvs
# tailor
Posté par Marc (site web personnel) . Évalué à 2.
[^] # Re: tailor
Posté par Marc (site web personnel) . Évalué à 2.
et avec le lien, c'est mieux!
[^] # Re: tailor
Posté par CrEv (site web personnel) . Évalué à 2.
Mais il n'a pas des limitations sur l'import des branches entre autre ?
[^] # Re: tailor
Posté par Marc (site web personnel) . Évalué à 2.
# De mon côté
Posté par serianox . Évalué à 3.
Je travaille en ce moment en interne avec Bazaar (ça doit faire un an que je me suis mis à l'utiliser). Il s'agit d'un projet relativement petit/gros, ça dépend comment on se place, mais l'original tourne autour des 200k lignes pour 12 ans de projets et 3k commits dans un dépot Svn.
Avec Bazaar, j'arrive à gérer mon trunk, des branches de dev, la synchronisation avec le dépot Svn original, un dépot Bazaar sur Launchpad, des dépots Git et mercurial et un dépot Svn vers lequel je reverse tout (en sachant que tout ces dépôts ont des arborescences bien différentes. Petite précision, je suis quasiment seul dessus.
L'ensemble marche relativement bien, l'import et l'export Svn se fait sans soucis, seul l'import Mercurial a été problématique (Mercurial -> Git -> fast-export -> Bazaar). Sinon, question performances, je travaille sur un vieux P4 et firefox me pose beaucoup plus de soucis de performances qu'une opération lourde avec Bazaar ;) (non, ce n'est pas un troll!)
# le merge des branches
Posté par goeb . Évalué à 1.
Je ne comprends pas bien pourquoi le merge de branches serait plus facile avec un système de gestion de version qu'un autre.
Il me semble en effet que merger un répertoire avec un autre revient à résoudre un problème identique quelque soit le système de gestion de version qu'on utilise (git, svn, mercurial,...). Il s'agit simplement d'avoir un outil suffisamment ergonomique (winmerge, vimdiff, patch, etc.).
Est-ce que quelqu'un pourrait expliquer ce problème récurrent de merge et ce qui permet de dire que git est mieux que svn par exemple ?
Merci.
[^] # Re: le merge des branches
Posté par ribwund . Évalué à 3.
Les informations disponibles sont donc plus importantes (quels sont les changesets inclus dans le merge, etc.) et permettent souvent de prendre de meilleurs décisions, notamment en cas de merge multiples entre 2 mêmes branches.
Il me semble que sous svn, svnmerge.py résoud partiellement ce problème.
Après, oui, les outils pour faire le merge sont généralement identiques. La différence peut être ,lors du 3-way merge, du choix de la version de base qui peut être moins pertinent avec svn.
# Repository -> dépôt
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Repository -> dépôt
Posté par CrEv (site web personnel) . Évalué à 3.
D'ailleurs comment traduire (proprement, avec des mots qui induisent du vrai sens hein, et qui prennent pas trois plombes à expliquer aux autres ce que je veux dire) commit et push par exemple ? ou fetch, update et pull ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.