> Par contre, en passant, y-a-t-il eu des problèmes lors de l'utilisation de git-svn (sur 18 mois je pense que oui) ?
Dans l'ensemble ca marche très bien. Faut juste pas chercher les problèmes à faire 150 sous branches croisées. Le seul vrai problème que j'ai eu c'est l'impossibilité de "svn dcommit" à cause de conflits au rebase après ~50 cherry pick pour une branche de maintenance. En refaisant l'opération par bloc de 10 c'est passé. Ça s'est produit une seule fois.
Autrement rien à signaler du coté de git-svn. Les quelques fois ou ça part en live, tu arrives toujours à sauver le coup avec un peu d'effort; contrairement à SVN ou j'ai déjà fini à faire des diff/patch à la mano.
Ça fait ce que je veux sans se vautrer et ça me coute 0 en admin et en formation.
> Mais mon problème est dans l'usage d'un tel outil par des personnes qui [...]
Git me semble une mauvaise option alors. La courbe d'apprentissage de git est assez ardue et je connais pas 2 personnes au monde qui l'utilise de la même façon. En plus avec un mélange de branche locale et remote mappées sur le repo SVN, ça ouvre encore plus de possibilités.
Soit tu leur trouves un VCS moderne avec une interface simple et tu penses que ça vaut le coup de former tout le monde. Grincheux et adaptes des GUI sous <MonOSFavoris, MonIDEFavoris> compris.
Soit tu les laisses sous SVN en écrivant bien les procédures pour qu'une branche soit mergée plus tard (surtout tu inclus une cible qui formate le code source dans ton processus de build). Et tu as une petite équipe sous git-svn qui gère le reste.
Tu peux aussi essayer de documenter *la* méthode de faire avec git dans ton projet. Maintenant on à du passer 50% de nos dev sous git, faut compter perdre 2/3 jours pour les mettre dans le bain et deux bonnes semaines à galérer. Et maintenant ils n'utilisent plus du tout git comme moi :-) D'une manière générale les gens sont passé à git-svn pour la souplesse de développement que ca offre plus que pour la gestion des branches SVN. Ils n'ont toujours pas le droit de merger dans le trunk ou dans les branches de release. Par contre ils ont bien compris que les branches SVN et des branches locales rendaient *leur* travail plus facile... On a que du Linux en station aussi.
[^] # Re: git-svn n'est pas parfait
Posté par ckyl . En réponse au journal migrations vers de vrai outils de dev.... Évalué à 2.
Dans l'ensemble ca marche très bien. Faut juste pas chercher les problèmes à faire 150 sous branches croisées. Le seul vrai problème que j'ai eu c'est l'impossibilité de "svn dcommit" à cause de conflits au rebase après ~50 cherry pick pour une branche de maintenance. En refaisant l'opération par bloc de 10 c'est passé. Ça s'est produit une seule fois.
Autrement rien à signaler du coté de git-svn. Les quelques fois ou ça part en live, tu arrives toujours à sauver le coup avec un peu d'effort; contrairement à SVN ou j'ai déjà fini à faire des diff/patch à la mano.
Ça fait ce que je veux sans se vautrer et ça me coute 0 en admin et en formation.
> Mais mon problème est dans l'usage d'un tel outil par des personnes qui [...]
Git me semble une mauvaise option alors. La courbe d'apprentissage de git est assez ardue et je connais pas 2 personnes au monde qui l'utilise de la même façon. En plus avec un mélange de branche locale et remote mappées sur le repo SVN, ça ouvre encore plus de possibilités.
Soit tu leur trouves un VCS moderne avec une interface simple et tu penses que ça vaut le coup de former tout le monde. Grincheux et adaptes des GUI sous <MonOSFavoris, MonIDEFavoris> compris.
Soit tu les laisses sous SVN en écrivant bien les procédures pour qu'une branche soit mergée plus tard (surtout tu inclus une cible qui formate le code source dans ton processus de build). Et tu as une petite équipe sous git-svn qui gère le reste.
Tu peux aussi essayer de documenter *la* méthode de faire avec git dans ton projet. Maintenant on à du passer 50% de nos dev sous git, faut compter perdre 2/3 jours pour les mettre dans le bain et deux bonnes semaines à galérer. Et maintenant ils n'utilisent plus du tout git comme moi :-) D'une manière générale les gens sont passé à git-svn pour la souplesse de développement que ca offre plus que pour la gestion des branches SVN. Ils n'ont toujours pas le droit de merger dans le trunk ou dans les branches de release. Par contre ils ont bien compris que les branches SVN et des branches locales rendaient *leur* travail plus facile... On a que du Linux en station aussi.