Depuis le 13 janvier, le dépôt du code source de GCC est entièrement passé sur Git. La tâche a été confiée au hacker moustachu Eric S. Raymond avec un délai assez court. Mais ce type est un monstre, il raconte ses trente jours de hack dans un billet impressionnant — des 580 Gio de RAM à sa maladie consécutive. Il y a un autre achèvement : le 13 janvier marque aussi la version 4.0 de Reposurgeon, l’outil d’esr pour convertir un dépôt d’un système de gestion de versions à un autre.
# me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par freem . Évalué à 2.
tout est dans le titre
[^] # Re: me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par Tonton Th (Mastodon) . Évalué à 6.
Dans son billet, esr ne parle pas du tout de cvs, il doit bien y avoir une raison…
[^] # Re: me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Pour être plus précis il écrit « from Subversion to Git » donc svn vers git, pas cvs vers git.
[^] # Re: me semblait pourtant qu'il existait déjà des outils pour passer de cvs à git?
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Sommaire
Et histoire de donner un exemple de cvs vers svn, voici mes notes d'octobre 2006, sur la conversion du dépôt CVS de l'association April :
Taille du dépôt CVS local
Taille du dépôt CVS côté serveur
Soit un total de 737760 KiB (et y a probablement des choses uniquement à archiver, pas à convertir, ou alors juste à dumper en attendant un éventuel réimport plus tard)
Création du SVN
(surtout ne pas oublier le 'fsfs', on n'en veut pas de la base Berkeley DB 'bdb'…)
(ça créé plein de fichiers dans /data/svn)
Bon, de toute façon, ce fichier ne sert à rien (qui existe encore en ayant été supprimé).
Pouf viré du CVS. On recommence tout…
Humm certes. (utilisé dans candidats.fr, cgi-bin, xray, software et htdocs apparemment). ça serait pas un tag par défaut dans CVS ? Et quelqu'un aurait appelé une branche 'start' ? On doit pouvoir forcer comme tag a priori.
Bon, toujours pass2… et ben on va oublier start alors…
Perdu, tu y as cru hein ? Bon reste plus qu'un choix alors…
OK on renomme, on choisit le jeu de caractères et on reprend.
YES !
Taille du dépôt SVN local
Taille du dépôt SVN sur le serveur
Vraie migration sur le serveur
# 30 jours
Posté par nonas . Évalué à 10.
C'est une blague ?
Ceux qui ont suivi un peu l'affaire se rappelleront que ça a commencé il y a au moins plus d'un an !
Je n'ai recherché que sur Phoronix :
- Décembre 2018, on en parle déjà, la RAM coute cher, migration de Python vers Golang : https://www.phoronix.com/scan.php?page=news_item&px=GCC-Reposurgeon-Py-To-Go-90
- Mai 2019, un autre développeur, Maxim Kuvyrkov s'y essaie aussi : https://www.phoronix.com/scan.php?page=news_item&px=GCC-SVN-To-Git-May-2019
- Mai 2019 toujours, esr change de machine : https://www.phoronix.com/scan.php?page=news_item&px=ESR-Threadripper-GCC-Git
- Septembre 2019, ça avance un peu mais il y a encore du travail : https://www.phoronix.com/scan.php?page=news_item&px=GCC-SVN-To-Git-September-2019
- Janvier 2020, on approche du but : https://www.phoronix.com/scan.php?page=news_item&px=GCC-Git-Possibly-This-Weekend
- Janvier 2020, enfin il a réussi : https://www.phoronix.com/scan.php?page=news_item&px=GCC-Is-On-Git
Donc je ne veux rien enlever à cette réussite, esr n'a pas travaillé là-dessus à plein temps pendant 1 an mais rapporter que ça n'a pris 30 jours, c'est faux.
[^] # Re: 30 jours
Posté par ZeroHeure . Évalué à -5.
Ni lui ni moi n'avons écrit que ça lui a pris 30 jours.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: 30 jours
Posté par nonas . Évalué à 9.
Alors je n'ai pas compris cette phrase :
[^] # Re: 30 jours
Posté par Tonton Th (Mastodon) . Évalué à 7.
Là, il se rend compte que son truc ne marchera jamais comme il est.
Et hop, il décide d'en refaire une grande partie…
[^] # Re: 30 jours
Posté par ZeroHeure . Évalué à 10. Dernière modification le 25 janvier 2020 à 13:00.
Oups, excuse-moi ! tu as raison. À force de réécriture je l'avais oublié — ce que c'est de vouloir tout dire en 5-6 lignes !… C'est 30 jours de rush final et 30 jours de maladie.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: 30 jours
Posté par Marc (site web personnel) . Évalué à 6.
Dans les archives on retrouves des traces des travaux en 2015:
https://gcc.gnu.org/ml/gcc/2015-08/msg00226.html
Ça fait un moment que ça traîne, mais ça s'est accéléré cette dernière année car les devs en avaient un peu marre que ça tourne en rond, d'où la deadline décidée au Cauldron 2019: https://gcc.gnu.org/wiki/GitConversion
# Port d'armes
Posté par liberforce (site web personnel) . Évalué à 10.
Je remercie cette conversion (et surout le coup de fatigue qui s'ensuivit) d'avoir mis ESR hors service pour une manifestation pro-armes.
Oui oui, on est que lundi…
# Support de reposurgeon et remarques sur les migrations
Posté par 6Ber Yeti . Évalué à 4.
Bonjour,
Reposurgeon pourrait être un outil tout à fait utile étant donné les failles / manque de fonctionnalités que l'on trouve dans la plupart des autres outils connus.
Compte tenu de l'auteur et des expériences sur lesquelles il se base, on peut imaginer qu'il gère un très grand nombre de cas.
Il faut noter que la documentation du projet liste et commente (ok, ça ressemble à un plaidoyer pro domo) les outils existants. Ca peut faire gagner du temps.
Le point bloquant est qu'il me semble manquer d'une communauté d'utilisateurs, avec les possibilités de support qui vont avec.
Néanmoins, même si l'outil est documenté, il ne me semble pas évident de l'exploiter tant la doc semble réalisée par un geek pour les geeks. J'entends par là des gens qui, en l'occurrence, connaissent par coeur les arcanes du VCS soure et du VCS cible.
Reste que la complexité d'une migration d'un VCS vers un autre ne dépend pas que de la complexité de chacun des 2 outils, mais aussi (surtout ?) des élucubrations réalisées par les développeurs qui peuvent conduire à un historique des plus complexes. Et je ne parle même pas de ceux qui mettent en conf des objets temporaires (dont ils oublient ensuite l'existence) ou des fichiers / arborescences vides dont ils oublient et l'existence et l'intérêt. Quand ce genre de "truc" s'est produit très tôt dans l'histoire du projet et que les intervenants ont beaucoup bougé… Plus personne n'est capable de déterminer si oui ou non il faut conserver ou oublier.
Bref, eu égard aux pratiques douteuses de certains projets, au manque de règles ou/et de contrôle du respect des règles, j'ai des doutes sur la faisabilité d'un outil tous usages, qui permet une migration en une fois de tout un historique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.