SVN comment résoudre les nouveaux conflits d’arborescence lorsque le fichier est ajouté sur deux twigs

Lors de la fusion de deux twigs (en utilisant SVN 1.6.1) où un fichier a été ajouté sur les deux twigs (puis travaillé dans ces twigs distinctes), je reçois l’un des nouveaux conflits d’arbre:

C foo.txt > local obstruction, incoming add upon merge 

J’ai besoin des changements des deux twigs, mais le conflit d’arbre ne me donne pas les fichiers habituels .working, .merge-left & .merge-right – ce qui est compréhensible en raison de la nature du conflit. Il y a pas mal de ces conflits et ceux où une suppression du même fichier a eu lieu sur chaque twig, 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 cela a été mentionné dans une ancienne version (2009) du document de conception “Tree Conflict” :

    Conflit XFAIL à partir de la fusion du fichier ajouté avec la version ajoutée

    Ce test effectue une fusion qui apporte un ajout de fichier sans historique dans un fichier versionné existant .
    Cela devrait être un conflit d’arbre sur le fichier de la variété « local obstruction, incoming add upon merge ». Correction des attentes dans r35341.

    (Ceci est aussi appelé “jumeaux maléfiques” dans ClearCase par ailleurs):
    un fichier est créé deux fois (ici “ajouté” deux fois) dans deux twigs différentes, créant deux historiques différents pour deux éléments différents, mais avec le même nom.

    La solution théorique consiste à fusionner manuellement ces fichiers (avec un outil de diff externe) dans la twig de destination « B2 ».

    Si vous travaillez toujours sur la twig source, le scénario idéal serait de supprimer ce fichier de la twig source B1 , de fusionner de B2 à B1 pour 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 ne se produisent que de B1 à B2 , une fusion manuelle sera nécessaire pour chaque fusion B1->B2 .

    J’ai trouvé un post suggérant une solution pour cela . C’est sur le sharepoint courir:

     svn resolve --accept working  

    qui réclamera les fichiers de la version locale comme étant OK.
    Vous pouvez l’exécuter pour un seul fichier ou des catalogues de projets entiers.

    Et si les changements entrants sont ceux que vous voulez? Je ne parviens pas à exécuter svn resolve – acceptez leur

    svn resolve –accept base

    Je viens juste de réussir à me caler en essayant de suivre les conseils de user619330 ci-dessus. La situation était la suivante: (1): j’avais ajouté des fichiers en travaillant sur ma twig initiale, branch1; (2) J’ai créé une nouvelle twig, branch2 pour un développement plus poussé, en la ramenant dans le tronc puis en fusionnant dans mes modifications depuis la twig 1. (3) Un collègue avait copié mes mods de twigment 1 vers sa propre twig, ajouté des mods supplémentaires, et ensuite fusionné au tronc; (4) Je voulais maintenant fusionner les dernières modifications de la ligne réseau dans ma twig de travail actuelle, twig2. Ceci est avec svn 1.6.17.

    La fusion avait des conflits d’arbre avec les nouveaux fichiers, et je voulais la nouvelle version du tronc où ils différaient, donc à partir d’une copie propre de branch2, j’ai fait un svn delete des fichiers en conflit, commettant ces changements de twig2 version de branch2 sans les fichiers en question), et a ensuite fait ma fusion à partir du tronc. Je l’ai fait parce que je voulais que l’historique corresponde à la version du tronc afin de ne plus avoir de problèmes plus tard lorsque j’essayerais de fusionner avec le tronc. La fusion s’est bien passée, j’ai eu la version de trunk des fichiers, svn st montre tout ok, puis j’ai touché plus de conflits d’arborescence en essayant de commettre les modifications, entre la suppression que j’avais faite précédemment et l’ajout de la fusion. A fait un svn résoudre les conflits en faveur de ma copie de travail (qui avait maintenant la version du trunk des fichiers), et l’a fait valider. Tout devrait être bon, non?

    Et bien non. Une mise à jour d’une autre copie de branch2 a abouti à l’ancienne version des fichiers (fusion par tronc). J’ai maintenant deux copies de travail différentes de branch2, supposément mises à jour vers la même version, avec deux versions différentes des fichiers, et les deux insistant sur le fait qu’elles sont entièrement à jour! Extraire une copie propre de branch2 a abouti à l’ancienne version (pré-réseau) des fichiers. Je les mets à jour manuellement dans la version de ligne de réseau et valide les modifications, retourne à ma première copie de travail (à partir de laquelle les modifications ont été apscopes à l’origine), tente de la mettre à jour et génère une erreur de sum de contrôle sur les fichiers en question. Soufflez le répertoire en question, obtenez une nouvelle version via la mise à jour, et enfin j’ai ce qui devrait être une bonne version de branch2 avec les modifications du tronc. J’espère. Développeur de mise en garde.