Pourquoi ai-je des conflits d'arbres dans Subversion?
J'avais une branche fonctionnelle de mon coffre et fusionnais périodiquement les modifications de mon coffre 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". Y a-t-il un moyen d'éviter cela à l'avenir?
Je ne pense pas que ceux-ci sont correctement signalés.
J'ai trouvé la solution en lisant le lien que Gary a donné (et je suggère de suivre cette voie).
Résumer pour résoudre le conflit d'arbre 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.
WARNING: "Valider votre répertoire de travail" signifie que la structure de votre sandbox sera celle que vous validez, donc si, par exemple, vous supprimez un fichier de votre sandbox, ils seront également supprimés du référentiel. Ceci ne s'applique qu'au répertoire en conflit.
De cette manière, nous suggérons à SVN de résoudre le conflit (--resolve), en acceptant la copie de travail dans votre sandbox (--accept working), de manière récursive (-R), à partir du répertoire en cours ( .).
Dans TortoiseSVN, sélectionner "Résolu" sur un clic droit résout réellement ce problème.
Subversion 1.6 a ajouté Tree Conflicts 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 modifier le texte de ce fichier. Une autre solution est lorsque vous effectuez un changement de nom Subversion d’un fichier que vous modifiez car il s’agit d’une action Add/Delete.
Le blog Subversion de CollabNet contient un excellent article sur Tree Conflicts .
D'après mon expérience, SVN crée un conflit d'arborescence LORSQUE je supprime un dossier. Il semble n'y avoir aucune raison.
Je suis le seul à travailler sur mon code -> supprimer un répertoire -> commit -> conflict!
J'ai hâte de passer à Git .
Je devrais clarifier - 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 semblent parfaitement corrects.
Exemple:
Fusionner/svn/projet/branches/une-branche/sources vers/svn/projet/trunk ---> conflit d'arbre
Fusionner/svn/projet/branches/une branche vers/svn/projet/trunk ---> OK
C'est peut-être une erreur stupide, mais ce n'est pas toujours évident car vous pensez que c'est quelque chose de plus compliqué.
Voici ce qui se passe ici: Vous créez un nouveau fichier sur votre coffre, puis vous le fusionnez dans votre branche. Lors de la fusion, ce fichier sera également créé dans votre branche.
Lorsque vous fusionnez votre branche dans le coffre, SVN essaie de faire la même chose: il voit qu'un fichier a été créé dans votre branche et essaie de le créer dans votre coffre dans le commit de fusion, mais il existe déjà! Cela crée un conflit d'arbre.
Le moyen d'éviter cela est de faire une fusion spéciale, une réintégration . Vous pouvez y parvenir avec le commutateur --reintegrate.
Vous pouvez en apprendre plus à ce sujet dans la documentation: http://svnbook.red-bean.com/fr/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
Toutefois, lors de la fusion de votre branche dans le tronc, les mathématiques sous-jacentes sont très différentes. Votre branche de fonctionnalité est maintenant un méli-mélo de modifications de lignes réseau dupliquées et de modifications de branches privées. Il n'y a donc pas de plage simple de révisions contiguës à copier. En spécifiant l'option --reintegrate, vous demandez à Subversion de répliquer soigneusement uniquement les modifications propres à votre branche. (Et en fait, cela se fait en comparant le dernier arbre de tronc avec le dernier arbre de branche: la différence qui en résulte est exactement ce que vous changez de branche!)
Après avoir réintégré une branche, il est vivement conseillé de la supprimer, sinon vous continuerez à avoir des conflits interconfessionnels chaque fois que vous fusionnerez dans le sens opposé: du coffre à 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 dans la v1.6
Cela peut être dû au fait que les clients de la même version n’ont pas été utilisés 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 car vous n'avez pas édité/supprimé/approché le 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à déjà fusionné une série de modifications que vous incluez dans votre fusion actuelle. Par exemple, dans le coffre, une personne a modifié un fichier, puis le renomme plus tard. Si, lors de votre première fusion, vous incluez la modification et qu'une seconde fusion inclut à la fois la modification et le changement de nom (essentiellement une suppression), vous obtiendrez é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 au moins sur les référentiels 1.4, je ne suis pas sûr que le mergetracking introduit dans la version 1.5 aide ici.
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
Puis copiez-les à nouveau à partir d'un autre répertoire racine dans la copie de travail qui les contient:
svn copy ROOT_DIR_NAME/SUB_DIR_NAME
Alors fais
svn cleanup
et
svn add *
Vous pouvez recevoir des avertissements avec le dernier, mais les ignorer et enfin
svn ci .
J'ai rencontré ce problème aujourd'hui aussi, 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 utilisé temporairement un fichier d'une assemblée d'une autre assemblée. J'y ai apporté beaucoup de modifications et je ne voulais pas orphelin de l'historique SVN. Dans ma branche, j'avais donc déplacé le fichier du dossier de l'autre assemblée. Ceci n'est pas suivi par SVN, il semble donc que le fichier est supprimé puis ajouté de nouveau. Cela finit par provoquer un conflit d'arbres.
J'ai résolu le problème en déplaçant le fichier en arrière, en validant et en fusionnant puis ma branche. Ensuite, j'ai déplacé le fichier par la suite. :) Cela semblait faire l'affaire.
J'ai eu ce même problème, et résolu en refaisant la fusion en utilisant ces instructions . Fondamentalement, il utilise la "fusion 2 URL" de SVN pour mettre à jour trunk à l'état actuel de votre branche, sans trop se soucier de l'historique et des conflits d'arborescence. M'a sauvé de la résolution manuelle de 114 conflits d'arbres.
Je ne sais pas si cela préserve l'histoire aussi bien que l'on voudrait, mais cela en valait la peine dans mon cas.
Un scénario que je rencontre parfois:
Supposons que vous avez un coffre, à partir duquel 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 de fonctionnalité/correctif que vous souhaitez fusionner ultérieurement dans la branche de version (car les modifications étaient suffisamment petites et que la fonctionnalité/correctif est important pour la version). .
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 explicitement fusionner les validations effectuées sur le tronc avant de créer une branche feature/fix qui a créé le répertoire "some-dir" avant de fusionner la branche feature/fix.
J'oublie souvent que cela n'est pas nécessaire chez Git.
Jusqu'à aujourd'hui, depuis au moins 3 mois, je rencontrais régulièrement des centaines de conflits d'arbres lorsque je tentais de fusionner une branche dans le coffre (avec TortoiseSVN 1.11 ). Que ce soit rebasé ou non, BTW. J'utilise TortoiseSVN depuis sa v1, en 2004, et je réintégraisais tout le temps les branches. Quelque chose a dû se passer récemment, je suppose?
Alors aujourd’hui, j’ai mené cette expérience simple et j’ai trouvé ce qui créait ces conflits insensés:
- J'ai bifurqué le coffre @ 393;
- J'ai modifié des dizaines de fichiers de manière aléatoire et en ai créé de nouveaux;
- J'ai commis. Maintenant @ 395 (un collègue est parti à 394 pour effectuer ses propres choses).
- Ensuite, j'ai essayé de réintégrer la branche dans le coffre, test uniquement; suite à la recommandation de TortoiseSVN dans l'assistant: "pour fusionner toutes les révisions (réintégrer), laissez cette case vide". Pour ce faire, j'ai cliqué avec le bouton droit de la souris sur le dossier de coffre et choisi "TortoiseSVN> Fusionner, à partir de/chemin/vers/branche", et je laissais la plage de tours vide , comme indiqué dans la boîte de dialogue.
Discussion: (voir pièce jointe)
toutes les révisions ... de quoi? J'ignorais que le client devait se référer à " toutes les révisions de la cible! ( trunk) ", car, dans le processus de réintégration de cette branche, j’ai vu la mention" Fusion de révisions 1-HEAD "! OMG. Pauvre diable, vous êtes ici en train de mourir. Cette branche est née @ 393, ne pouvez-vous pas lire son acte de naissance, pour l'amour de Dieu? 
Résolution:
- Contrairement à ce que recommande le wiz, spécifiez une plage qui couvre TOUTES les révisions de ... la vie de la branche! donc, 394-HEAD ;
- maintenant, lancez à nouveau ce test de fusion et obtenez un cigare. (
![see second attachment]()
).
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 signaler cela avec eux.