Pourquoi ai-je des conflits d'arbres dans Subversion?

J'avais une branche caractéristique de mon tronc et je fusionnais périodiquement les changements de mon tronc dans ma branche et tout fonctionnait bien. Aujourd'hui, je suis allé fusionner la branche dans le tronc et tous les fichiers qui ont été ajoutés à mon tronc 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.

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

Pour résumer le conflit d'arborescence lors de la validation de 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, il sera également supprimé 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 à l'intérieur de votre sandbox ( --accept working), récursivement ( -R), à partir du répertoire courant ( .).

Dans TortoiseSVN, la sélection de "Résolu" sur le clic droit résout en fait ce problème.

Subversion 1.6 a ajouté des conflits d'arbre pour couvrir les conflits au niveau du répertoire. Un bon exemple serait lorsque vous supprimez localement un fichier, puis une mise à jour essaie de réduire le texte sur ce fichier. Un autre est lorsque vous avez un changement de nom de subversion d'un fichier que vous modifiez car il s'agit d'une action Ajouter / Supprimer.

Le blog Subversion de CollabNet contient un excellent article sur les conflits d'arbres .

D'après mon expérience, SVN crée un conflit d'arborescence LORSQUE je supprime un dossier. Il ne semble y avoir aucune raison.

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

J'ai hâte de passer à Git .

Je dois préciser - j'utilise Subclipse . C'est probablement le problème! Encore une fois, j'ai hâte de changer ...

Je ne sais pas si cela vous arrive, mais parfois je choisis le mauvais répertoire à fusionner et j'obtiens cette erreur même si tous les fichiers apparaissent complètement bien.

Exemple:

Fusionner / svn / Projet / branches / certaines branches / Sources vers / svn / Projet / tronc ---> Conflit d'arbre

Fusionner / svn / Project / branches / some-branch vers / svn / Project / trunk ---> OK

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

Ce qui se passe ici est le suivant: vous créez un nouveau fichier sur votre tronc, puis vous le fusionnez dans votre branche. Dans le commit de fusion, ce fichier sera également créé dans votre branche.

Lorsque vous fusionnez votre branche dans le tronc, SVN essaie à nouveau de faire de même: il voit qu'un fichier a été créé dans votre branche, et essaie de le créer dans votre tronc dans le commit de fusion, 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 --reintegratecommutateur.

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 vers le tronc, les mathématiques sous-jacentes sont très différentes. Votre branche de fonctionnalité est maintenant un méli-mélo à la fois de modifications de tronc dupliqué et de modifications de branche privée, il n'y a donc pas de gamme de révisions contiguës simples à copier. En spécifiant l'option --reintegrate, vous demandez à Subversion de reproduire soigneusement uniquement les modifications propres à votre branche. (Et en fait, il fait cela en comparant le dernier arbre de tronc avec le dernier arbre de branche: la différence résultante est exactement vos changements de branche!)

Après avoir réintégré une branche, il est fortement conseillé de la supprimer, sinon vous continuerez à avoir des conflits d'arbres à chaque fois que vous fusionnerez dans l'autre sens: du tronc à votre branche. (Pour exactement la même raison que celle décrite précédemment.)

Il y a un moyen de contourner cela aussi, mais je ne l'ai jamais essayé. Vous pouvez le lire dans cet article: Réintégration de la branche Subversion en v1.6

Cela peut être dû au fait de ne pas utiliser les mêmes clients de version partout.

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

Si vous rencontrez des conflits d'arborescence qui n'ont pas de sens parce que vous n'avez pas modifié / supprimé / approché du fichier, il y a également de bonnes chances qu'il y ait une erreur dans la commande de fusion.

Ce qui peut arriver, c'est que vous avez déjà fusionné un ensemble des modifications que vous incluez dans votre fusion actuelle. Par exemple, dans le tronc, quelqu'un a modifié un fichier, puis le renomme plus tard. Si dans votre première fusion vous incluez la modification, puis dans une deuxième fusion incluez à la fois la modification et le renommage (essentiellement une suppression), cela vous donnera également un conflit d'arborescence. La raison en est que la modification précédemment fusionnée apparaît alors comme la vôtre et que la suppression ne sera donc pas effectuée automatiquement.

Cela peut se produire sur les référentiels 1.4 au moins, je ne sais pas si le mergetracking introduit dans 1.5 aide ici.

Jusqu'à aujourd'hui, car depuis au moins 3 mois, j'ai régulièrement rencontré des centaines de conflits d'arbres en tentant de fusionner une branche dans le tronc (en utilisant TortoiseSVN 1.11 ). Qu'il soit rebasé ou non, BTW. J'utilise TortoiseSVN depuis sa v1, en 2004, et j'ai toujours réintégré des branches. Quelque chose a dû se produire récemment, je suppose?

Alors aujourd'hui, j'ai exécuté cette expérience simple, et j'ai trouvé ce qui créait ces conflits fous:

1. J'ai bifurqué le coffre @ 393;
2. J'ai modifié des dizaines de fichiers au hasard, ainsi que d'en créer de nouveaux;
3. Je me suis engagé. Maintenant @ 395 (un collègue a déboursé à 394 pour effectuer ses propres trucs).
4. Ensuite, j'ai essayé de réintégrer la branche dans le coffre, test seulement; suivant la recommandation de TortoiseSVN dans l'assistant: "pour fusionner toutes les révisions (réintégrer), laissez cette case vide". Pour y parvenir, j'ai fait un clic droit sur le dossier trunk, et choisi "TortoiseSVN> Merge, from / path / to / branch", et j'ai laissé la plage de régime vide , comme indiqué dans la boîte de dialogue.

Discussion: (voir pièce jointe)

toutes les révisions ... de quoi? Je ne savais pas que le client devait faire référence à " toutes les révisions de la cible! (Tronc)", car, dans le processus de réintégration de cette branche, j'ai vu la mention "Fusionner les révisions 1-HEAD"! OMG. Pauvre diable, tu tombes ici à mort. Cette branche est née @ 393, ne pouvez-vous pas lire son acte de naissance, pour l'amour de Dieu?

Résolution:

1. Contrairement à ce qui est conseillé par le wiz, précisez une gamme, qui couvre TOUTES les révisions de ... la vie de la branche! par conséquent, 394-HEAD ;
2. exécutez à nouveau ce test de fusion et obtenez un cigare. ( ).

Moral: Je ne comprends pas pourquoi ils n'ont toujours pas corrigé ce bogue, car il en est un, je suis désolé. Je devrais prendre le temps de rapporter cela avec eux.

J'ai également rencontré ce problème aujourd'hui, bien que mon problème particulier ne soit probablement pas lié au vôtre. Après avoir inspecté la liste des fichiers, j'ai réalisé ce que j'avais fait - j'avais temporairement utilisé un fichier dans un assemblage d'un autre assemblage. J'y ai apporté de nombreuses modifications et je ne voulais pas rendre orphelin l'historique SVN, donc dans ma branche, j'avais déplacé le fichier du dossier de l'autre assembly. Ce n'est pas suivi par SVN, il semble donc que le fichier soit supprimé puis rajouté. Cela finit par provoquer un conflit d'arbre.

J'ai résolu le problème en replaçant le fichier, en validant, puis en fusionnant ma branche. Ensuite, j'ai reculé le fichier. :) Cela semblait faire l'affaire.

J'avais un problème similaire. La seule chose qui a réellement fonctionné pour moi a été de supprimer les sous-répertoires en conflit avec:

svn delete --force ./SUB_DIR_NAME

Ensuite, copiez-les à nouveau à partir d'un autre répertoire racine de la copie de travail qui les contient avec:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Alors fais

svn cleanup

et

svn add *

Vous pourriez recevoir des avertissements avec le dernier, mais ignorez-les et enfin

svn ci .

J'ai eu ce même problème et l'ai résolu en refaisant la fusion à l'aide de ces instructions . Fondamentalement, il utilise la "fusion de 2 URL" de SVN pour mettre à jour trunkl'état actuel de votre branche, sans trop se soucier de l'historique et des conflits d'arborescence. M'a sauvé de la correction manuelle de 114 conflits d'arborescence.

Je ne sais pas si elle préserve l'histoire aussi bien qu'on le souhaiterait, mais cela en valait la peine dans mon cas.

Un scénario que je rencontre parfois:

Supposons que vous ayez une jonction à partir de laquelle vous avez créé une branche de publication. Après quelques modifications sur le tronc (en particulier la création du répertoire "some-dir"), vous créez une branche fonctionnalité / correction que vous souhaitez également fusionner ultérieurement dans la branche de publication (car les modifications étaient suffisamment petites et la fonctionnalité / correction est importante pour la publication) .

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

Si vous essayez ensuite de fusionner la branche feature / fix directement dans la branche release, vous obtiendrez un conflit d'arborescence (même si le répertoire n'existait même pas dans la branche feature / fix):

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

Vous devez donc fusionner explicitement les validations qui ont été effectuées sur le tronc avant de créer la branche feature / fix qui a créé le répertoire "some-dir" avant de fusionner la branche feature / fix.

J'oublie souvent cela car ce n'est pas nécessaire dans git.