SVN comment résoudre de nouveaux conflits d'arbres lorsque le fichier est ajouté sur deux branches

Question

Lors de la fusion deux branches (en utilisant SVN 1.6.1) où un fichier a été ajouté sur les deux branches (et a ensuite travaillé dans ces branches distinctes) Je reçois un des nouveaux conflits d'arbres:

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

J'ai besoin des changements des deux branches, mais le conflit d'arbre ne me donne pas la .working habituelle, .merge gauche et fichiers .merge droit - ce qui est compréhensible en raison de la nature du conflit. Il y a tout à fait quelques-unes 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 redbean SVN (pour 1.6) ne couvre pas cette situation.

Answer 1

Comme il a été mentionné dans une version plus ancienne (2009) du "Arbre conflit" document:

  

XFAIL conflit de fusion d'ajouter sur fichier versionné

     

Ce test fait une fusion qui apporte un ajout de fichiers sans histoire sur un   fichier existant versionné .
  Cela devrait être un conflit d'arbre sur le fichier de la variété de local obstruction, incoming add upon merge. attentes fixes r35341.

(Ceci est aussi appelé « jumeaux mal » ClearCase par la voie):
un fichier est créé deux fois (ici « ajouté » deux fois) dans deux branches différentes, créant ainsi deux histoires différentes 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 comparaison externe) dans la branche de destination « B2 ».

Si vous travaillez encore sur la branche source, le scénario idéal serait de supprimer ce fichier de la branche source B1, fusion de retour de B2 à B1 afin de rendre ce fichier visible sur B1 (vous serez alors travailler sur la même élément).
Si une fusion est impossible retour, car se fond ne se produit de B1 à B2, puis une fusion manuelle sera nécessaire pour chaque B1->B2 fusionne.

Answer 2

J'ai trouvé un poste proposant une solution pour que . Il est sur le point d'exécuter:

svn resolve --accept working <YourPath>

qui réclamera les fichiers de la version locale comme OK.
Vous pouvez l'exécuter pour seul fichier ou ensemble de catalogues de projets.

Answer 3

  

Que faire si les modifications entrantes sont celles que vous voulez? Je suis incapable de courir svn résoudre --accept leur plein

svn résolution de base --accept

Answer 4

Je viens réussi à me caler assez bien essayer de suivre les conseils de user619330 ci-dessus. La situation était la suivante: (1): J'avais ajouté des fichiers tout en travaillant sur ma branche initiale, Branch1; (2) Je créé une nouvelle branche, succursale2 pour le développement ultérieur, branchement hors tension du tronc, puis la fusion dans mes changements de Branch1 (3) Un collègue avait copié mes mods de Branch1 à sa propre branche, a ajouté mods supplémentaires, puis fusionné sur le tronc; (4) Je voulais maintenant fusionner les derniers changements de tronc dans ma branche de travail actuelle, succursale2. C'est avec svn 1.6.17.

La fusion avait des conflits d'arbres avec les nouveaux fichiers, et je voulais la nouvelle version du tronc où ils diffèrent, donc d'une copie propre de succursale2, je l'ai fait un svn supprimer des fichiers en conflit, commis ces changements de Branch2 (ainsi la création d'une version temporaire de succursale2 sans les fichiers en question), puis a fait ma fusion du tronc. Je l'ai fait parce que je voulais l'histoire de correspondre à la version du tronc afin que je n'aurais pas plus de problèmes plus tard lors d'une tentative de fusionner le tronc. Fusionner est bien passé, je suis la version du tronc des fichiers, svn st montre tout ok, puis je frappe plus de conflits d'arbres tout en essayant de valider les modifications, entre la delete j'avais fait plus tôt et l'ajout de la fusion. Est-ce une volonté svn des conflits en faveur de ma copie de travail (qui avait maintenant la version trunk des fichiers), et a pour commettre. Tout devrait être bon, droit?

Eh bien, non. Une mise à jour d'une autre copie de succursale2 a donné lieu à l'ancienne version des fichiers (de fusion pré-tronc). Alors maintenant, j'ai deux copies de travail différentes de succursale2, prétendument mis à jour à la même version, avec deux versions différentes des fichiers, et les deux insistais qu'ils sont entièrement à jour! Vérification une copie propre de succursale2 a donné lieu à l'ancienne version (pré-tronc) des fichiers. Mettre à jour manuellement ces à la version du tronc et valider les modifications, revenir à ma première copie de travail (à partir de laquelle j'avais soumis le tronc change à l'origine), essayez de le mettre à jour, et maintenant obtenir une erreur de contrôle sur les fichiers en question. Souffler le répertoire en question loin, obtenir une nouvelle version via mise à jour, et enfin je ce qui devrait être une bonne version de succursale2 avec les modifications du tronc. J'espère. développeur caveat.