SVN, comme tu le dis si bien, n'aimes pas (ne connaît pas ?) les merges.
Donc si tu as un historique à la Git, soit avec une arborescence assez complexe, tu ne peux l'envoyer tel-quel dans SVN, car ce dernier sera perdu au premier merge Git (c'est pour ça que je me permet de dire que SVN ne connaît pas les merges : il permet de les effectuer, mais ils ne représentent rien). Tu dois donc aplatir ton historique avant de le passer à SVN.
Au final, tu te retrouves avec les même problèmes... mais tu te bats avec les outils de git, notamment la possibilité de faire toute ta m... crasse en local, et de n'envoyer le tout qu'une fois content du résultat. Mais tu perds quand même une bonne partie de l'intérêt de Git...
Personnellement, j'utilise git-svn au travail, car je connais bien et aime git, mais je pense qu'une version tout-git apporte un réel plus (ou plutôt un réel moins d'ennuis !)
# git-svn n'est pas parfait
Posté par dohzya . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 3.
SVN, comme tu le dis si bien, n'aimes pas (ne connaît pas ?) les merges.
Donc si tu as un historique à la Git, soit avec une arborescence assez complexe, tu ne peux l'envoyer tel-quel dans SVN, car ce dernier sera perdu au premier merge Git (c'est pour ça que je me permet de dire que SVN ne connaît pas les merges : il permet de les effectuer, mais ils ne représentent rien). Tu dois donc aplatir ton historique avant de le passer à SVN.
Au final, tu te retrouves avec les même problèmes... mais tu te bats avec les outils de git, notamment la possibilité de faire toute ta m... crasse en local, et de n'envoyer le tout qu'une fois content du résultat. Mais tu perds quand même une bonne partie de l'intérêt de Git...
Personnellement, j'utilise git-svn au travail, car je connais bien et aime git, mais je pense qu'une version tout-git apporte un réel plus (ou plutôt un réel moins d'ennuis !)