Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).
Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
Workflow commun:
- Ton master local correspond au trunk/
- Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
- Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.
Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.
Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)
[^] # Re: Git svn
Posté par ckyl . En réponse au journal Git malgré moi. Évalué à 3.
Tu as la puissance de git en local tout en ayant la possibilité de garder ton repo SVN et donc n'avoir rien à changer dans tes confs et pour les autres. C'est très très très pratique quand tu es dans une infrastructure assez lourde et que tu ne peux pas changer de SCM facilement (Au choix problème de gestion, management, technique, formation des autres devs, manque d'outils etc.).
Tout les devs avec qui j'ai bossé et qui ont essayé ne peuvent plus s'en passer tellement ca leur facilite la vie. Pourtant ils étaient tous sceptiques.
Workflow commun:
- Ton master local correspond au trunk/
- Possibilité de mapper des branches locales vers des branches subversion. On créé une branche par feature. Tout ceux qui bossent sur cette feature utilise cette branche. On peut donc bosser sur une feature que les autres devs utilisent git ou pas
- Pour les petits patchs solo, une branche locale (aussi rattachée au trunk) un dcommit et c'est poussé dans le trunk.
Après ca reste git, compliqué d'accès. Trop de choix et de facon de faire. Marrant presque aucuns de ceux qui utilise git-svn ne l'utilisent de la même facon (merge puis dcommit VS dcommit, rebase VS merge, suivi de branch). Bref chacun fait a sa sauce, ce qui implique de perdre pas mal de temps au départ et n'aide pas à son adoption.
Bref c'est l'outil idéal si comme contrainte tu as "Le dépot du projet sur lequel je bosse est SVN". Attention j'ai pas dit que c'était l'outil idéal ;-)