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.
# Support de reposurgeon et remarques sur les migrations
Posté par 6Ber Yeti . En réponse au journal Le compilateur GCC passe à Git. É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.