Peut-être qu’il suffit de faire l’import en ciblant le dossier trunk sans l’option « shema standard » pour garder l’historique ?
IE au lieu d’importer _squelettes_/html5up_alpha/ en disant « il y a un trunk et des branche » importer directement _squelettes_/html5up_alpha/trunk ?
Cédric je comprends pas bien ce que tu veux faire exactement pour régler ce problème ?
C'est le principe des modèles dont on parle, le mode mono ne considére
pas de schema standard mais juste un trunk.
Mais meme en ciblant trunk sans préciser de schema, la racine restera
trunl et donc ce qui s'est passé en amont (de l'arborescence) ne sera
pas pris en compte.
Je prends par exemple le squelettes ahuntsic.
Le dernier commit est le mien pour le passage en trunk.
Sous Git on ne voit que ce commit, pour moi c'est pas terrible.
On peut essayer autrement sur celui-ci.
Oui dans cas :
* détruire le dépot git
* svn revert du commit
* script d'import avec le modele mono
Il y a aura un ménage subgit à faire par la suite pour supprimer les
reliquats de config mais pas bloquant dans l'immédiat.
Ok, mais comment on fait un revert d'un passage en trunk ?
Je ne vois pas comment faire.
Via svn merge de ce que je comprends de la doc : previous_version
étant l'état avant mise en place du trunk.
svn merge -r [current_version]:[previous_version] [repository_url]
Je sais pas si il faut faire un svn merge ou un svn copy depuis une ancienne revision ?
Ce qui est quand même bizarre qu’il perde tout l’historique sur la copie, on a pas ce soucis avec un git svn clone par exemple, qui suit bien l’historique.
Et pour info j’ai donc essayé
$ bash ./ImportOneRepository.sh -r _squelettes_/ahuntsic/trunk -o spip-contrib-squelettes -m zone_mono -t ahuntsic_trunk
Je sais pas si il faut faire un svn merge ou un svn copy depuis une
ancienne revision ?
Ce qui est quand même bizarre qu’il perde tout l’historique sur la copie,
on a pas ce soucis avec un git svn clone par exemple, qui suit bien
l’historique.
Et pour info j’ai donc essayé
$ bash ./ImportOneRepository.sh -r _squelettes_/ahuntsic/trunk -o
spip-contrib-squelettes -m zone_mono -t ahuntsic_trunk
(en ajoutant une option -t au script pour pouvoir lui indiquer le target)
c’est pas mieux en effet
Oui c'est bien mon avis.
On peut lister mes commits, il sont repérables.
Et on vire le repo git.
Là ou je ne suis pas du tout à l'aise c'est de revert ce passage en trunk.
Si quelqu'un peut le faire ce soir je renvoie l'import mono sur ces plugins
et au moins on aura les logs complets.
Autre chose pourrait-on aussi rajouter une option au script qui
permettrait de choisir le nom du repo de destination dans le cas ou on a
une arborescence xxx/yyy/zzz souvent zzz est pas déterministe.
Je sais pas si il faut faire un svn merge ou un svn copy depuis une ancienne revision ?
Ce qui est quand même bizarre qu’il perde tout l’historique sur la copie, on a pas ce soucis avec un git svn clone par exemple, qui suit bien l’historique.
Et pour info j’ai donc essayé
$ bash ./ImportOneRepository.sh -r _squelettes_/ahuntsic/trunk -o spip-contrib-squelettes -m zone_mono -t ahuntsic_trunk
(en ajoutant une option -t au script pour pouvoir lui indiquer le target) c’est pas mieux en effet Connexion · GitLab
Bah si on invente des options qui n'existe pas.
Pour info le script n'utilise pas git-svn il n'y a rien de commun avec
subgit si ce n'est l'objectif de traduire svn en git.
Là ou je ne suis pas du tout à l'aise c'est de revert ce passage en trunk.
Si quelqu'un peut le faire ce soir je renvoie l'import mono sur ces plugins et au moins on aura les logs complets.
Bah je peux tester on peut faire ça ensemble tantôt.
Autre chose pourrait-on aussi rajouter une option au script qui permettrait de choisir le nom du repo de destination dans le cas ou on a une arborescence xxx/yyy/zzz souvent zzz est pas déterministe.
Je ne comprends pas ce que tu veux faire et le résultat attendu. As tu
un exemple plus précis ?
Je sais pas si il faut faire un svn merge ou un svn copy depuis une ancienne revision ?
Ce qui est quand même bizarre qu’il perde tout l’historique sur la copie, on a pas ce soucis avec un git svn clone par exemple, qui suit bien l’historique.
Je n’ai pas tout suivi ; j’espère que les choses se sont arrangées finalement et que ce n’est pas un point bloquant à la migration vers un/une autre vcs/forge.
Pour info le script n’utilise pas git-svn il n’y a rien de commun avec
subgit si ce n’est l’objectif de traduire svn en git.
Intéressant, faudrait que je jette un oeil curieux…
Au début des échanges j’essayais de retrouver dans mes favoris ce que ça me rappelait. Presqu’en vain (en plus le site http://progetti.arstecnica.it/tailor/ n’existe plus… mais j’ai fini par retrouver sa trace sur une forge de μ$) https://github.com/lelit/tailor ! C’est ça que me rappelait la discussion. Je n’ai toujours pas eu l’occasion de le tester
