Re: Migration SVN->GIT et historiques
Cerdic <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <e8908fdb-f0fb-4fed-b761-d651c3b38420@Spark> |
Concernant macrosession : on voit sur svn qu’il a été renommé depuis « visiteur » et c’est là que ça casse l’historique dans la migration vers git.spip.net https://zone.spip.net/trac/spip-zone/log/spip-zone/_plugins_/macrosession/trunk?action=stop_on_copy&mode=follow_copy&rev=120891&stop_rev=&limit=100 Dans ce cas précis on peut refaire la migration en lui indiquant le repertoire visiteur comme une source supplémentaire et on aura tout l’historique En l’occurence on retrouve ça sur le repo archive sur github https://github.com/Cerdic/spip-zone-plugins/commit/6ab543c4f5a227036e8c23b6897c0fc29a732045#diff-e1bedf01fd9677717e509ee10cd33986 et partant de là on peut remonter à la suite de l’historique https://github.com/Cerdic/spip-zone-plugins/commits/53e187fb48feabec84557e81c4401d66ed762c0e/visiteur qui est donc bien archivé sur ce projet. Le projet archive est migré via git-svn et non via subgit et comprend tout _plugins_ et non dossier par dossier. C’est pour ça qu’il ne perd pas d’historique (sauf en cas de déplacement vers ou depuis _plugins_ donc) Donc là si tu le veux on peut re-migrer macrosession avec l’historique complet Concernant cachelab/ on peut voir sur l’historique SVN que là le passage en trunk n’a pas été fait dans les règles de l’art et on a perdu l’historique aussi sur le dossier (on ne peut pas suivre sur copie) https://zone.spip.net/trac/spip-zone/log/spip-zone/_plugins_/cachelab/trunk?action=stop_on_copy&mode=follow_copy&rev=120891&stop_rev=&limit=100 mais il faut descendre dans les sous-dossier pour avoir l’historique https://zone.spip.net/trac/spip-zone/changeset/111783/spip-zone/_plugins_/cachelab/trunk là typiquement on saura pas récupérer plus d’historique sur git.spip.net Par contre sur le github archive : on a bien pareil https://github.com/Cerdic/spip-zone-plugins/commits/master?after=456d769278f064515692af95345be608e747b4f9+69&path%5B%5D=cachelab&path%5B%5D=trunk mais on peut remonter au commit précédent sur cachelab https://github.com/Cerdic/spip-zone-plugins/commits/7196c31a006a5adaf950ffdae136b9b2d7e39920/cachelab On a donc bien dans les 2 cas un historique complet dans le git archive sur github :) -- Cédric Le 30 janv. 2020 à 13:15 +0100, JLuc <[email protected]>, a écrit : > Le 30/01/2020 à 10:32, Cerdic a écrit : > > Comme on a semble-t-il pas de solution simple pour récupérer ces historiques en git, et que perdre de l’histoire c’est > > toujours embêtant - sans parler du problème que cela peut poser dans la recherche de bugs, j’ai fait le test d’importer > > en git-svn les répertoires complets _squelettes_ et _plugins_ : > > > > https://github.com/Cerdic/spip-zone-squelettes > > https://github.com/Cerdic/spip-zone-plugins > > > L’idée est de stocker ces 2 gros repos gitqui font ~3Go au total sur github pour pouvoir aller y piocher dedans > > l’historique en cas de besoin. > > > Il faut maintenant que chacun aille voir les repositories avec lesquels il est habitué à travailler et qui comptent pour > > lui, et regarde si l’historique est satisfaisant ou non, et si les morceaux plus anciens manquants sont bien retrouvable > > via les 2 projets archives sur github > > J'ai regardé sur 2 plugins : macrosession et cachelab. > J'étais passé en trunk il y a longtemps et il y a eu beaucoup de commits dessus depuis. > Sur ces plugins et sur les repos github/Cerdic j'ai vu que l'historique s'arrêtait au passage en trunk, > pareil que sur git.spip. > > > Peut-être que malgré notre attention il reste des cas avec un historique tronqué qu’on peut réparer, je vous invite donc > > à nous faire remonter les cas les plus gênants pour vous qu’on regarde ça pour dire si oui ou non on peut faire mieux. > > J'ai pas tout compris donc je ne sais pas si c'est normal ou pas... > Mais pour ces plugins en tout cas, ça remplit pas la fonction décrite de sauvegarde l'historique. > > Concernant ces plugins en particulier ça ne me gênera pas pour la recherche de bug (yen a pas !) > mais ça doit peut être vous alerter sur ce qui a réellement été sauvegardé. > Et je comprend pas l'intérêt de faire un dépot à part sur github s'il a les mêmes limitations que git.spip > > JL > > > > _______________________________________________ > liste: https://listes.rezo.net/mailman/listinfo/spip-dev > doc: https://www.spip.net/ > dev: https://core.spip.net/ > irc://irc.freenode.net/spip