SVN comment résoudre les nouveaux conflits d'arborescence lorsque le fichier est ajouté sur deux branches
Lors de la fusion de plusieurs branches (à l'aide de SVN 1.6.1) dans lesquelles un fichier a été ajouté sur les deux branches (puis traité dans ces branches distinctes), un des nouveaux conflits d'arborescence apparaît:
C foo.txt
> local obstruction, incoming add upon merge
J'ai besoin des modifications des deux branches, mais le conflit d'arbre ne me donne pas les fichiers .working, .merge-left & .merge-right habituels - ce qui est compréhensible du fait de la nature du conflit. Il existe un bon nombre de ces conflits, et ceux où une suppression du même fichier a eu lieu sur chaque branche, mais ils sont simples à résoudre.
Comment puis-je résoudre ce problème? Le livre SVN Redbean (pour 1.6) ne couvre pas cette situation.
Comme mentionné dans une ancienne version (2009) du document "Tree Conflict" document:
Conflit XFAIL résultant de la fusion d'un fichier ajouté à la version
Ce test effectue une fusion qui ajoute un fichier sans historique à un fichier versionné existant .
Cela devrait être un conflit d’arbre sur le fichier de la 'local obstruction, incoming add upon merge' variété. Correction des attentes dans r35341.
(Ceci est aussi appelé "les jumeaux maléfiques" dans ClearCase):
Un fichier est créé deux fois (ici "ajoutés" deux fois) dans deux branches différentes, créant ainsi deux historiques différents pour deux éléments différents, mais avec le même nom.
La solution théorique est de fusionner manuellement ces fichiers (avec un outil de diff externe) dans la branche de destination 'B2 '.
Si vous travaillez toujours sur la branche source, l'idéal serait de supprimer ce fichier de la branche source B1, fusionne de B2 à B1 afin de rendre ce fichier visible sur B1 _ (vous travaillerez ensuite sur le même élément).
Si une fusion n'est pas possible car les fusions ont lieu uniquement à partir de B1 à B2, une fusion manuelle sera nécessaire pour chaque B1->B2 fusionne.
J'ai trouvé un post suggérant une solution pour cela . Il est sur le point de courir:
svn resolve --accept working <YourPath>
qui réclamera les fichiers de version locale comme étant OK.
Vous pouvez l'exécuter pour un seul fichier ou pour des catalogues de projets entiers.
Et si les changements entrants sont ceux que vous voulez? Je ne parviens pas à exécuter svn resol --accept the--full
svn resolution --accept base
J'ai juste réussi à me caler complètement en essayant de suivre les conseils de user619330 ci-dessus. La situation était la suivante: (1): J'avais ajouté des fichiers lorsque je travaillais sur ma branche initiale, branche1; (2) J'ai créé une nouvelle branche, branche2 à développer, la ramifiant du tronc, puis fusionnant mes modifications depuis la branche1 (3) Un collègue a copié mes mods de branche1 dans sa propre branche, ajoute d'autres mods, et ensuite fusionné dans le coffre; (4) Je voulais maintenant fusionner les dernières modifications du tronc dans ma branche de travail actuelle, branch2. C'est avec svn 1.6.17.
La fusion avait des conflits d’arbre avec les nouveaux fichiers, et je voulais que la nouvelle version soit stockée dans le coffre où ils différaient. Ainsi, d’une copie vierge de branch2, j’ai effacé les fichiers en conflit par la commande svn. version de branch2 sans les fichiers en question), puis ma fusion depuis le coffre. Je l’ai fait parce que je voulais que l’historique corresponde à la version de la corbeille afin que je n’aie plus de problèmes plus tard lors de la fusion. La fusion s'est bien déroulée, j'ai la version principale des fichiers, svn st indique que tout va bien, puis je me suis heurté à plus de conflits d'arborescence en essayant de valider les modifications, entre la suppression que j'avais effectuée précédemment et l'ajout de la fusion. Est-ce qu'un svn résoudre les conflits en faveur de ma copie de travail (qui avait maintenant la version principale des fichiers), et le faire valider? Tout devrait être bon, non?
Et bien non. Une mise à jour d'une autre copie de branch2 a entraîné l'ancienne version des fichiers (fusion préalable à la jonction). Alors maintenant, j'ai deux copies de travail différentes de branch2, supposément mises à jour dans la même version, avec deux versions différentes des fichiers, et les deux insistent pour être à jour! L'extraction d'une copie vierge de branch2 a abouti à l'ancienne version des fichiers (antérieure à la connexion). Je les mets manuellement à jour dans la version de coffre et valide les modifications, je retourne à ma première copie de travail (à partir de laquelle j'avais initialement soumis les modifications de jonction), j'essaie de la mettre à jour et j'obtiens maintenant une erreur de somme de contrôle sur les fichiers en question. Soufflez le répertoire en question, obtenez une nouvelle version via une mise à jour, et enfin j'ai ce qui devrait être une bonne version de branch2 avec les modifications de la jonction. J'espère. Développeur de mise en garde.