Problème avec la commande svn merge de subversion
laurris
Membre
J'ai un souci avec subversion, je sais que ça n'a pas de rapport avec cocoa mais comme je me trouve bloqué dans mon développement, je m'en remets à vos expériences.
J'ai créé une branche dans mon dépot. J'en arrive à un point où le code de ma branche est à un stade abouti. Donc je voudrais réintégrer tous mes changements présents dans mabranche vers le trunk. J'ai bien suivi le manuel qui dit qu'il faut spécifier la révision de création de la branche ET la révision actuelle. Donc ça donne : cd trunk PUIS svn merge -r 28:54 url_de_la_branche.
Et là c'est le drame. j'ai plein de fichiers marqués C comme conflit. Bien sûr, subversion ne me dit pas d'où viennent les conflits et comment les résoudre !
Si vous avez eu le même genre de pb, peut-être savez vous comment s'en sortir. Autre option: effacer entierement le trunk et copier la branche à la place. Mais je ne voudrais pas en arriver là .
J'ai créé une branche dans mon dépot. J'en arrive à un point où le code de ma branche est à un stade abouti. Donc je voudrais réintégrer tous mes changements présents dans mabranche vers le trunk. J'ai bien suivi le manuel qui dit qu'il faut spécifier la révision de création de la branche ET la révision actuelle. Donc ça donne : cd trunk PUIS svn merge -r 28:54 url_de_la_branche.
Et là c'est le drame. j'ai plein de fichiers marqués C comme conflit. Bien sûr, subversion ne me dit pas d'où viennent les conflits et comment les résoudre !
Si vous avez eu le même genre de pb, peut-être savez vous comment s'en sortir. Autre option: effacer entierement le trunk et copier la branche à la place. Mais je ne voudrais pas en arriver là .
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Dans le fichier lui-même, les conflits sont signalés par des
[tt]>>>>>>> .mine
// le code perso
========
// le code updaté
<<<<<< .rXX[/tt]
À côté de cela, SVN crée 3 fichiers, un qui porte l'extension [tt].mine[/tt] qui contient ta version, un qui porte l'extension [tt].rXX[/tt] qui contient le code de la révision courante de la copie locale, et un [tt].rYY[/tt] qui contient la dernière révision qui est sur le serveur. Ces fichiers sont supprimés lorsque tu résouds le conflit, donc inutile de le faire toi-même.
D'après ce que je comprends, le conflit a lieu quand la version en cours a été modifiée par rapport à la version attendue (serveur ou copie locale). Or j'ai fait un update avant le svn merge.
Est-ce qu'il y a un moyen de passer outre les conflits pour intégrer la version branche dans le trunk quelles que soient les mofifications en cours ?
En gros, pour chaque fichier, il prend les deux versions, et essaie d'obtenir un fichier cohérent.
Dans certains cas, il ne pourra pas obtenir quelque-chose de cohérent, d'où les conflits.
Par exemple, si dans une version, il y a "i++" et dans l'autre "i--" au même niveau, il ne va pas choisir pour toi lequel est OK -> conflit
J'ai une version Trunk revision 10 (T-r10) que je copie en une branche B-r10. Ensuite je bosse sur la branche jusqu'à B-r15.
Ensuite je veux appliquer les modifs Br10 à Br15 à la version du trunk. Est-ce qu'il faut nécessairement que le trunk n'ait pas été modifié entre les versions 10 à 15 ?
Dans mon cas, je l'ai un peu retouché le trunk entre r10 et r15 donc ça doit être ça. Me trompe-je ou il faudrait que je revienne à le version 10 uniquement sur le trunk, avant le merge, pour éviter les conflits ?
Maintenant si tu es sur que la révision Br15 est la bonne, il n'y a rien qui t'empêche de la reprendre (en copiant/collant son contenu - n'oublie pas que SVN crée toujours plusieurs fichiers en cas de conflit) et de résoudre le conflit de cette manière.
Oui, car il va essayer de merger les modifications que tu as faites dans le trunk et celles que tu as faites via ta branche.
Quand ça ne colle pas, conflit.
Finalement j'ai suivi la procédure manuelle pour les resoudre: remplacer le fichier avec la version de la branche puis 'svn resolved fichier' donc tout est bien qui finit bien. Merci pour vos avis qui m'ont encouragé à trouver une solution.
J'espère que dans xCode 3 on aura une interface pour résoudre les conflits. Serait bien pratique.
Dans Xcode, Subversion est géré sous la rubrique "Source Code Managment" (ou SCM), il faut que tu configures ton projet (dans l'inspecteur), puis Xcode est capable de faire le gros des opérations.
Je parlais surtout de comment résoudre les conflits à l'intérieur d'un fichier. Au lieu d'avoir les marques difficilement lisibles du genre >>>>>> .mine, on aurait un éditeur splitté verticalement en deux versions et on choisirait la bonne. Comme le fait déjà filemerge quand on compare deux fichiers sauf que l'éditeur serait intégré à xcode. D'ailleurs je sais que xCode 3 a un genre de filemerge intégré, si ça se trouve il lit aussi les fichiers conflictuels de svn, faudrait vérifier ...