Re: Migration SVN->GIT et historiques

Le 30/01/2020 à 10:32, Cerdic a écrit :
> Bonjour,
> 
> suite à la campagne de migration des plugins et squelettes de spip-zone 
> en SVN vers des projets git indépendants sur git.spip.net est apparu un 
> soucis sur la reprise de l’historique :
>   * chaque fois que dans l’historique SVN on a déplacé un dossier xxxxxx 
> vers un sous-dossier xxxxxx/trunk ou xxxxxx/branches/yyyy cela casse 
> l’historique dans la migration.
> 
> On a donc de manière générale, des historiques partiels uniquement sur 
> les projets git de https://git.spip.net/spip-contrib-squelettes et 
> https://git.spip.net/spip-contrib-extensions
> 
> On a donc fait une évaluation des dégats, et pour un certain nombre de 
> projets on a repris l’historique sur SVN en remontant au moment du 
> déplacement et en rejouant par dessus les commits qui avaient été fait 
> par la suite.
> 
> En gros on est repassé de xxxxxx/trunk vers xxxxxx quand il y avait 
> moins d’une vingtaine de commits à reprendre.
> 
> Dans certains cas spéciaux pour lesquels les plugins avaient changé de 
> répertoire au cours de leur vie on a fait une migration avec des 
> réglages personalisés.
> 
> Cela concerne au total une 100aine de plugins et squelettes pour 
> lesquels on a récupéré tout ou partie de l’historique.
> 
> 
je suis pas sur de saisir. En gros d'avoir transformé des /plugin/ en 
/plugin/trunk empeche la conservation de l'historique dans tous les cas, 
mais il est possible de revenir à /plugin/ puis de remettre dessus ce 
qui a été fait en /trunk. ceci est possible en historique court car ca 
peut se faire manuellement, mais ce serait complexe en historique long ?

> ## En l’état actuel :
> 
> Pour les squelettes la situation est à peu près saine, car on a eu 
> beaucoup moins de mouvement et les historiques sont plus simples
> 
> Pour les plugins :
>    - il n’y a a priori plus de plugins avec un historique court pour 
> lesquels on peut reprendre facilement l’historique sur SVN pour migrer
>    - mais de manière générale on perd des queues d’historiques lointains
> 
> ## Proposition de rustine
> 
> 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
> 
> Je les ai mis sur mon compte le temps de tester mais on peut les migrer 
> dans l’orga SPIP ensuite.
> 
je pense que c'est une bonne idée, si on arrive à assurer la perenttié 
de ces 2 dépots.

> 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.
> Cela nous permettra de fermer définitivement le SVN et le trac quand on 
> le décidera (et d’ici là on peut resynchroniser de temps en temps ces 2 
> projets archives)
> 
> ## Ce qu’il faut faire pour valider la migration vers git
> 
> 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
> 
> 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.
> 
> Et une fois que tout le monde est OK et que personne ne crie plus au 
> scandale, on peut décider que la nouvelle référence des projets est 
> git.spip.net, le svn n’étant plus qu’un miroir temporaire le temps que 
> tout le monde migre.
> 
> C’est important de le noter car pour tous les plugins migrés dans trunk, 
> les branches créées dans git ne seront pas créeés dans SVN, qui va donc 
> petit à petit être de moins en moins complet.
> 
> A vos remarques et retours,
> 
> 
> -- 
> Cédric
>