La je ne suis pas d'accord avec toi. Avec git-svn c'est pas parfait, mais ca répond à 99% des besoins AMHA.
On souhaitait passer à un modèle de dev basé sur les branches dans notre équipe, en ayant pour contrainte de devoir garder SVN comme dépôt officiel. De plus on ne souhaitait pas former tout les devs à un nouveau VCS.
On est donc parti sur git-svn depuis ~18 mois. Les résultats sont très satisfaisants: aucun problème pour merger ~40 branches (donc certaines de plus de 12 mois), souplesse de git pour les devs qui en ont besoin, les autres restent à SVN ça évite de former 30 personnes à git pour rien. Tout les essais de merge avec SVN (et svnmerge) avaient foiré avant. Bref ca fait ce qu'on veut, sans avoir couté cher.
Effectivement le problème du backend SVN est que tu perds les informations de merge, donc ca devient le bordel quand tu cherches dans l'historique. Faut être un peu organisé. Mais y'a pas de miracle...
Notre utilisation:
- Une branche par feature (donc merge trunk->branche pour se synchro, et branche -> trunk pour l'intégration)
- Une branche pour chaque branche de release (cherry pick trunk -> release et tags de la branche pour chaque version mineure)
- Branche git locale pour tout ce qui le nécessite (et possibilité de la publier sur le SVN si on constate que c'est plus compliqué que prévu)
Après tout dépend de ton cahier des charges. Un VCS moderne apporte plus de fonctionnalités mais ça coute cher en déploiement/formation/intégration. Tu ne peux pas faire ça en 1 mois et tu auras à former tout nouveau dev dans ton équipe. Surtout que y'a 1000 façons d'utiliser git.
git-svn ca permet de faire des merges sur un repo SVN sans rien changer pour les autres (tu les fais co leur branche et zou). Et pour les devs qui migrent ça apporte le confort de git.
Perso je ne m'amuserais pas avec des passerelles lecture/écriture sur un repo.
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 5.
On souhaitait passer à un modèle de dev basé sur les branches dans notre équipe, en ayant pour contrainte de devoir garder SVN comme dépôt officiel. De plus on ne souhaitait pas former tout les devs à un nouveau VCS.
On est donc parti sur git-svn depuis ~18 mois. Les résultats sont très satisfaisants: aucun problème pour merger ~40 branches (donc certaines de plus de 12 mois), souplesse de git pour les devs qui en ont besoin, les autres restent à SVN ça évite de former 30 personnes à git pour rien. Tout les essais de merge avec SVN (et svnmerge) avaient foiré avant. Bref ca fait ce qu'on veut, sans avoir couté cher.
Effectivement le problème du backend SVN est que tu perds les informations de merge, donc ca devient le bordel quand tu cherches dans l'historique. Faut être un peu organisé. Mais y'a pas de miracle...
Notre utilisation:
- Une branche par feature (donc merge trunk->branche pour se synchro, et branche -> trunk pour l'intégration)
- Une branche pour chaque branche de release (cherry pick trunk -> release et tags de la branche pour chaque version mineure)
- Branche git locale pour tout ce qui le nécessite (et possibilité de la publier sur le SVN si on constate que c'est plus compliqué que prévu)
Après tout dépend de ton cahier des charges. Un VCS moderne apporte plus de fonctionnalités mais ça coute cher en déploiement/formation/intégration. Tu ne peux pas faire ça en 1 mois et tu auras à former tout nouveau dev dans ton équipe. Surtout que y'a 1000 façons d'utiliser git.
git-svn ca permet de faire des merges sur un repo SVN sans rien changer pour les autres (tu les fais co leur branche et zou). Et pour les devs qui migrent ça apporte le confort de git.
Perso je ne m'amuserais pas avec des passerelles lecture/écriture sur un repo.