"svn merge" ne sait merger que des commits sans se souvenir si ils ont déjà été mergé ou non. C'est une commande qui ne devrait pas être destiné à l'utilisateur final.
svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.
[^] # Re: Merge
Posté par ckyl . En réponse à la dépêche Subversion (SVN) 1.5 est disponible. Évalué à 6.
svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.