- Possibilité de mapper des branches locales vers des branches subversion.
L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
Quand je développe une nouvelle fonctionnalité non triviale (disons 5 patches), je n'écris pas directement les 5 patches du premier coup directement sans erreur. J'expérimente quelque chose, je me rends compte que ce que j'écris n'est pas la meilleur solution, je change en cours de route. Je teste, il y a un bug dans le deuxième patch, je le corrige. Bref, pendant ce processus, j'ai besoin de modifier le deuxième patch sur les 5 commits en local. Puis je me rends compte que le troisième patch contient des debugs que je ne voulais pas commiter, et une faute de grammaire dans les commentaires. Je corrige. Ensuite, je propose mes 5 patches propres à la relecture, ils sont approuvés, puis inclus dans master.
Si j'avais fait tout cela avec svn, j'aurais eu deux possibilités:
- soit je propose un seul patch contenant l'équivalent de mes 5 patches. Ça va être plus difficile au relecteur de comprendre et d'être sûr qu'il n'y a pas d'erreur car on perd le découpage en patches élémentaires.
- soit je commit au fur et à mesure mes patches dans la branche svn. Mais toujours pareil, le relecteur doit se taper les erreurs de développement. Ça lui fait du travail supplémentaire. Le temps du relecteur n'est pas une ressource illimité, il risque de ne pas avoir le temps et de ne pas accepter mon travail.
Et puis personnellement, même si je propose un seul patch sur svn, git reste un bon outil pour moi pour conserver mes patches d'expérimentation, y revenir, etc. On ne peut pas faire ça avec svn. Quilt est pas mal pour ça, mais l'interface de git est tout de même meilleure et plus simple.
[^] # Re: Git svn
Posté par Alban Crequy (site web personnel) . En réponse au journal Git malgré moi. Évalué à 1.
L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
Quand je développe une nouvelle fonctionnalité non triviale (disons 5 patches), je n'écris pas directement les 5 patches du premier coup directement sans erreur. J'expérimente quelque chose, je me rends compte que ce que j'écris n'est pas la meilleur solution, je change en cours de route. Je teste, il y a un bug dans le deuxième patch, je le corrige. Bref, pendant ce processus, j'ai besoin de modifier le deuxième patch sur les 5 commits en local. Puis je me rends compte que le troisième patch contient des debugs que je ne voulais pas commiter, et une faute de grammaire dans les commentaires. Je corrige. Ensuite, je propose mes 5 patches propres à la relecture, ils sont approuvés, puis inclus dans master.
Si j'avais fait tout cela avec svn, j'aurais eu deux possibilités:
- soit je propose un seul patch contenant l'équivalent de mes 5 patches. Ça va être plus difficile au relecteur de comprendre et d'être sûr qu'il n'y a pas d'erreur car on perd le découpage en patches élémentaires.
- soit je commit au fur et à mesure mes patches dans la branche svn. Mais toujours pareil, le relecteur doit se taper les erreurs de développement. Ça lui fait du travail supplémentaire. Le temps du relecteur n'est pas une ressource illimité, il risque de ne pas avoir le temps et de ne pas accepter mon travail.
Et puis personnellement, même si je propose un seul patch sur svn, git reste un bon outil pour moi pour conserver mes patches d'expérimentation, y revenir, etc. On ne peut pas faire ça avec svn. Quilt est pas mal pour ça, mais l'interface de git est tout de même meilleure et plus simple.