> L'intérêt? Pourquoi ne pas fait directement une branche dans svn?
En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.
> C'est pas un peu abusé du concept, juste un point de vue.
C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.
> À te lire, on a l'impression que les autres devs n'y ont pas accès
Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.
> Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.
> Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
La j'ai pas compris la question.
Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.
[^] # Re: Git svn
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 3.
En fait c'est mal exprimé en effet. Tu crée ta branche subversion et tu peux associé N de tes branches git à cette branche subversion. En général une seule suffit, mais des fois c'est pratique d'en faire deux. Pour bosser sur des trucs séparés qui iront dans la même branche SVN. Évidement l'intêret de la branche SVN, c'est que les gens qui utilisent SVN peuvent y avoir accès.
Note que tu gardes le côté pratique de git, par ce qu'un commit git n'entraine pas immédiatement un commit SVN. Tu décides quand les pousser.
> C'est pas un peu abusé du concept, juste un point de vue.
C'est un point de vue en effet. Libre à chacun de faire comme il le veut. L'expérience m'a montré que mettre de nouveaux devs ou des refactoring important dans le trunk était une très mauvaise idée. Tu te retrouves avec un trunk non stable, ou avec des fonctionalités que tu ne veux pas encore ds la branche officielle donc impossibilité de releaser (voir même souvent de rollbacker). Avoir une branche par feature ca permet de prendre son temps pour que tout arrive à maturation, et de réfléchir au moment où tu intègres dans la branche principale. Ne pas créer de branche, ca veut dire que quelqu'un bosse en sousmarin donc tu n'as aucune idée de son changeset. C'est une question d'équilibre c'est sur. Il n'y a pas de bonne solution, il y a des solutions qui fonctionne avec ton projet et ton équipe.
> À te lire, on a l'impression que les autres devs n'y ont pas accès
Si bien sur, c'est une branche SVN. Ce que t'apporte git-svn, ce sont les branches locales et la possibilité créer une ou plusieurs branches git à partir d'une branche SVN. Tu travailles en locale avec tes branches git. Et tu pousses tes commits sur le SVN en une commande, de même tu mets à jour en une commande. Bref tu as la puissance de git sur la gestion des branches, des merges, des cherry-pick, du stash etc. tout en utilisant très simplement SVN. Hormis 2 ou 3 pièges ca fonctionne très bien, j'ai jamais réussi à le planter.
> Et le "merge" tu le fais où et quand? Sachant que c'est(c'était?) un inconvénient de SVN.
Oui c'est un des gros interet de passer à git-svn. Les merge (ou rebase) sont fait par git. Ensuite tu pousses le résultat sur le SVN. L'inconvéniant c'est que à cause du backend SVN tu perds les informations de merge dans git une fois que c'est poussé. Y'a pas de miracle.
> Les revisions SVN sont donc beaucoup plus espacées, ça se passe comment si tu veu revoir l'évolution de telle partie de code?
La j'ai pas compris la question.
Pour résumé comme dit plus haut. git-svn c'est le meilleur client svn, même si tu veux pas merger.