Pourquoi est-ce que j'ai des conflits d'arborescence dans Subversion ?

Question

J'avais une branche de fonctionnalités de mon tronc et je fusionnais périodiquement les modifications de mon tronc dans ma branche et tout fonctionnait bien.Aujourd'hui, je suis allé fusionner la branche dans le coffre et tous les fichiers ajoutés à mon coffre après la création de ma branche ont été signalés comme un "conflit d'arborescence".Existe-t-il un moyen d'éviter cela à l'avenir ?

Je ne pense pas que ceux-ci soient correctement signalés.

Answer 1

J'ai trouvé la solution en lisant le lien donné par Gary (et je suggère de suivre cette voie).

Résumer pour résoudre le conflit d'arborescence valider votre répertoire de travail avec le client SVN 1.6.x, vous pouvez utiliser :

svn resolve --accept working -R .

où . est le répertoire en conflit.

AVERTISSEMENT: "Valider votre répertoire de travail" signifie que votre structure sandbox sera celle que vous validez, donc si, par exemple, vous avez supprimé un fichier de votre sandbox, ils seront également supprimés du référentiel.Cela s'applique uniquement au répertoire en conflit.

De cette façon, nous suggérons à SVN de résoudre le conflit (--resolve), en acceptant la copie de travail dans votre sandbox (--accept working), récursivement (-R), à partir du répertoire courant (.).

Dans TortoiseSVN, sélectionner "Résolu" avec un clic droit résout en fait ce problème.

Answer 2

Subversion 1.6 ajouté conflits arbres pour couvrir les conflits au niveau du répertoire. Un bon exemple serait lorsque vous supprimez un fichier localement puis une mise à jour tente d'apporter un texte rétrograder sur ce fichier. Une autre est quand vous vous avez une Rename subversion d'un fichier que vous éditez depuis est un Ajouter / Supprimer action.

Blog Subversion CollabNet a un grand article sur Arbre conflits .

Answer 3

Dans mon expérience, SVN crée un conflit d'arbre WHENEVER supprimer un dossier. Il semble y avoir aucune raison.

Je suis le seul à travailler sur mon code -> supprimer un répertoire -> commit -> conflit

Je ne peux pas attendre pour passer à Git .

Je dois préciser - j'utiliser Subclipse. C'est probablement le problème! Encore une fois, je ne peux pas attendre pour passer ...

Answer 4

Je ne sais pas si cela vous arrive, mais parfois je choisis le mauvais répertoire pour fusionner et je reçois cette erreur, même si tous les fichiers apparaissent tout à fait bien.

Exemple:

Fusionner / svn / projet / branches / certaines branches / Sources à / svn / projet / trunk ---> Arbre conflit

Fusionner / svn / projet / branches / une branche à / svn / projet / trunk ---> OK

Cela pourrait être une erreur stupide, mais ce n'est pas toujours évident parce que vous pensez qu'il est quelque chose de plus compliqué.

Answer 5

Qu'est-ce qui se passe ici est la suivante: Vous créez un nouveau fichier sur votre coffre, puis vous fusionnez dans votre branche. Dans la fusion commit ce fichier sera créé dans votre branche également.

Lors de la fusion de votre branche dans le tronc, SVN essaie de faire la même chose à nouveau: Il voit qu'un fichier a été créé dans votre branche, et essaie de créer dans votre coffre dans la fusion commit, mais il existe déjà! Cela crée un conflit d'arbre.

La façon d'éviter cela est de faire une fusion spéciale, une réintégration . Vous pouvez y parvenir avec le commutateur --reintegrate.

Vous pouvez lire à ce sujet dans la documentation: http://svnbook.red -bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

  

Cependant, lors de la fusion de votre branche avec le tronc, le sous-jacent   les mathématiques sont tout à fait différentes. Votre branche de fonctionnalité est maintenant un méli-mélo   des deux modifications du tronc dupliqués et des changements de succursales privées, donc   il n'y a pas simple, plage contiguë de révisions à copier sur. Par   spécifiant l'option --reintegrate, vous demandez à Subversion   soigneusement reproduire uniquement les changements propres à votre succursale. (Et en   fait, il le fait en comparant le dernier arbre du tronc avec la dernière   arbre branche: la différence résultant est exactement vos modifications de la branche)

Après une branche, il réintégration est fortement conseillé de l'enlever, sinon vous continuerez à obtenir treeconflicts chaque fois que vous fusionnez dans l'autre sens: du tronc à votre succursale. (Pour exactement la même raison que décrit précédemment.)

Il y a un moyen de contourner cela aussi, mais je jamais essayé. Vous pouvez le lire dans ce message: réintégration branche Subversion dans v1.6

Answer 6

Cela peut être causé par ne pas utiliser les mêmes clients version partout.

L'utilisation d'un client version 1.5 et une version 1.6 client vers le même référentiel peut créer ce genre de problème. (Je me suis mordue.)

Answer 7

Si vous rencontrez des conflits d'arbres qui ne font pas de sens parce que vous ne pas modifier / supprimer / venez approcher le fichier, il y a aussi une bonne chance qu'il y avait une erreur dans la commande de fusion.

Qu'est-ce qui peut arriver est que vous avez déjà fusionné déjà un tas de changements que vous incluez dans votre fusion actuelle. Par exemple, dans quelqu'un tronc édité un fichier, puis renomme plus tard. Si dans votre première fusion, vous incluez le modifier, puis dans une seconde fusion comprennent à la fois la modification et le changement de nom (essentiellement supprimer), il vous donnera également un conflit d'arbre. La raison est que l'édition précédemment fusionné apparaît alors comme vous-même, et donc la supprimer ne sera pas exécutée automatiquement.

Cela peut se produire sur 1.4 référentiels au moins, je ne suis pas sûr que le mergetracking introduit 1,5 aide ici.

Answer 8

Je suis tombé sur ce problème aujourd'hui et, bien que ma question particulière est probablement pas liée à la vôtre. Après avoir inspecté la liste des fichiers, j'ai réalisé ce que je l'avais fait - j'avais temporairement utilise un fichier dans un ensemble d'une autre assemblée. J'ai fait beaucoup de changements à elle et ne voulait pas orphelin l'histoire SVN, donc dans ma branche, j'avais déplacé le fichier sur à partir du dossier de l'autre ensemble. Ce ne sont pas suivis par SVN, il ressemble le fichier est supprimé et puis rajoutées. Cela finit par provoquer un conflit d'arbre.

Je résolu le problème en déplaçant le fichier en arrière, engageant et puis fusionner ma branche. Ensuite, je me suis déplacé le fichier en arrière par la suite. :) Cela semblait faire l'affaire.

Answer 9

J'ai eu un problème similaire. La seule chose qui a effectivement travaillé pour moi était de supprimer les sous-répertoires en conflit avec:

svn delete --force ./SUB_DIR_NAME

Ensuite, copiez les nouveau d'un autre répertoire racine dans la copie de travail qui les a avec:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Ensuite, faites

svn cleanup

et

svn add *

Vous pouvez obtenir des avertissements avec le dernier, mais il suffit de les ignorer et enfin

svn ci .

Answer 10

J'ai eu ce même problème, et résolu par re-faire de la fusion en utilisant ces instructions . En fait, il utilise « la fusion 2-URL » de SVN mettre à jour trunk à l'état actuel de votre branche, sans se soucier tant de choses sur les conflits d'histoire et d'arbres. M'a sauvé de fixer manuellement 114 conflits d'arbres.

Je ne sais pas si elle conserve l'histoire aussi bien qu'on le voudrait, mais ça valait le coup dans mon cas.

Answer 11

Un scénario que je lance parfois dans:

Supposons que vous avez un tronc, à partir de laquelle vous avez créé une branche de sortie. Après quelques changements sur le tronc (en créant notamment de répertoire « some-dir »), vous créez une fonction / fix branche que vous souhaitez fusionner plus tard dans la branche de sortie ainsi (parce que les changements sont assez petites et la fonction / fix est important pour la libération) .

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

Si vous essayez ensuite de fusionner la fonction / fixer branche directement dans la branche de sortie, vous obtiendrez un conflit d'arbre (même si le répertoire n'existait même pas dans la branche fonction / fixe):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

Vous devez fusionner explicitement les commits qui ont été faits sur le tronc avant de créer fonction / fixer la branche qui a créé le répertoire « some-dir » avant de fusionner la branche fonction / fixe.

J'oublie souvent que ce n'est pas nécessaire git.

Answer 12

Jusqu'à ce jour, car depuis au moins il y a 3 mois, je rencontre régulièrement des centaines de conflits d'arbres lors d'une tentative de fusionner une branche dans le tronc (en utilisant TortoiseSVN 1,11 ). Que ce soit rebasées ou non, d'ailleurs. J'utilise TortoiseSVN depuis sa v1, en 2004, et je l'habitude de réintégrer les branches tout le temps. Quelque chose a dû se passer récemment, je suppose?

Aujourd'hui, je couru cette expérience simple, et je trouve ce qui crée ces conflits fous:

1. Je bifurquait le tronc @ 393;
2. J'ai modifié des dizaines de fichiers au hasard, ainsi que créer de nouveaux;
3. Je me suis engagé. Maintenant @ 395 (un collègue bifurquait à 394 pour effectuer ses propres trucs).
4. Alors j'ai essayé de réintégrer la branche dans le tronc, seul test; suite à la recommandation de TortoiseSVN dans l'assistant: « pour fusionner toutes les révisions (réintégrer), laissez cette case vide ». Pour ce faire, je cliqué, bouton droit sur le dossier du tronc, et choisi « TortoiseSVN> Fusion, de / chemin / vers / branche », et I quitté la plage de régime vide , comme le conseille la boîte de dialogue.

Discussion: (voir pièce jointe)

toutes les révisions ... de quoi? Je ne savais pas que le client doit avoir référence à « toutes les révisions de la cible! (tronc) », comme, dans le processus de réintégration de cette branche, j'ai vu la mention "révisions 1-Merging HEAD"! OMG. Pauvre diable, vous êtes tomber à la mort ici. Cette branche est né @ 393, tu ne peux pas lire son acte de naissance, pour l'amour de Dieu?

Résolution:

1. Contrairement à ce que est conseillé par le wiz, ne spécifiez une gamme, qui couvre toutes les révisions de ... la vie de la branche! Par conséquent, 394-HEAD ;
2. Exécuter maintenant ce test de fusion à nouveau, et obtenir un cigare. ( ).

Moral: Je ne comprends pas pourquoi ils ont toujours pas fixé ce bug, car il est l'un, je suis désolé. Je devrais prendre le temps de le signaler avec eux.