2011-09-03 1 views
1

J'ai un problème lors de la fusion du tronc dans une branche de développement dans une arborescence SVN.Résolution d'un problème de fusion de ligne à branche dans svn

L'histoire du projet est la suivante. Il a commencé avec un seul tronc. A propos de la révision 207, la première branche a été créée. Ensuite, à la révision 331, la branche d'intérêt a été séparée du tronc.

Nous sommes maintenant à la révision 384. La plupart des changements entre 331 ont été effectués sur la branche d'intérêt, mais quelques-uns ont été effectués indépendamment sur le tronc.

Afin que la branche reste en phase avec le tronc, je voulais fusionner à partir du tronc dans celui-ci. Donc, je l'ai fait dûment:

svn merge ^/trunk . 

Cependant, je trouve que toutes sortes de conflits sautent vers le haut. Quelques conflits que je pourrais comprendre, mais presque tous les répertoires et fichiers de l'arborescence sont affectés. Ce qui est encore pire, c'est que la plupart de ces prétendus conflits sont en fait des changements qui ont été commis sur le tronc entre 207 et 331, et sont donc déjà incorporés dans la branche, car la branche était séparée du tronc .

Ce qui est pire que cela, c'est qu'un certain nombre de conflits supposés sont des conflits d'arborescence, impliquant des fichiers qui ont été supprimés ou renommés, encore une fois entre 207 et 331. Parce qu'ils n'existent plus sur la branche. Je n'existe pas là, je ne vois aucun moyen de résoudre le problème. Une correction est compliquée car pour presque tous les fichiers, la branche est correcte, et donc une fusion, suivie par l'acceptation de la copie de branche, ne me laisse rien à valider, donc le serveur n'a jamais l'indice que la fusion a en fait été réalisée.

J'ai essayé plusieurs choses à corriger:

svn cleanup 

Il me semblait que cela ne fait rien pertinent.

svn checkout ^/branches/branch-of-interest new-local-copy-of-branch-of-interest 

Le problème a persisté dans la nouvelle copie de la vérification.

svn merge --record-only -r207:331 ^/trunk . 

Fait intéressant, la fusion soi-disant "record-only" a également essayé de changer les fichiers dans ma copie locale!

svn merge ^/trunk . 

Cela a généré un tas de conflits et de conflits d'arbres, même après je luttais avec l'enregistrement unique de fusion, la résolution laborieusement les changements (le dossier uniquement Merge) appliquée.

Je devrais également dire que quand j'ai commencé, mon client exécutait 1.6.17 et le serveur 1.4.6. Cependant, le serveur a depuis été mis à niveau vers la version 1.6.17 et le problème persiste.

Y a-t-il un moyen de résoudre ce problème? Faire une fusion complète et résoudre les fichiers un à un prendrait énormément de temps, et pour l'instant - pour des raisons évidentes - je n'ai même pas confiance que la prochaine fois que mon SVN n'essaierait pas de faire la même chose moi encore une fois.

+0

Vous pourriez regarder à travers les journaux pour quelque chose d'étrange sur le tronc. J'ai vu un problème similaire une fois lorsque le tronc a été retiré puis restauré via une fusion. –

+0

Merci John. En fait, je suppose que c'est peut-être parce que la base de données du référentiel SVN est toujours au format 1.4, et est donc incapable de garder une trace des fusions. J'ai contacté le mainteneur du repo, lui demandant de le mettre à jour. Je vais voir si cela résout le problème. – Valtandor

Répondre

0

Il s'avère que le problème résidait dans la version de la base de données associée au référentiel.Même après la mise à niveau du client et du serveur vers la dernière version, la base de données était toujours dans un ancien format qui ne suivait pas les fusions.

La mise à niveau vers la dernière version de la base de données a résolu le problème et m'a permis de fusionner sans problème. En particulier, nous avons utilisé ces commandes sur la machine hébergeant le serveur et repo:

svnadmin upgrade /path/to/repository 
svn-populate-node-origins-index /path/to/repository 
Questions connexes