Conflits lors de la fusion dans la branche de certaines modifications du code supprimé

Question

Nous avons récemment créé une branche avec une version de code personnalisée pour un certain client. Nous travaillons sur les deux branches en même temps, en effectuant des changements «communs» dans le tronc, puis en les fusionnant à la branche.

Récemment, nous sommes arrivés à une situation difficile. En trunk/bar.c nous avons (parmi d'autres) une fonction foo(). Maintenant, dans branch/bar.c la fonction a été supprimée, car il n'y a aucune utilité pour cela. Les problèmes se produisent lorsque foo() est modifié dans le trunk. Lorsque nous fusionnons les changements dans la branche ("Merge range of revisions"), TortoiseSVN "3-way fusion" outil montre un conflit sur la méthode (c'est ennuyeux mais je peux voir quelques raisons dans cela), mais il fait aussi montrer un ensemble beaucoup d'autres changements dans le fichier - qui semblent apparaître de nulle part (ressemble un peu à si elle voulait montrer tous les changements effectués entre le tronc et la branche). Et cela rend la fusion beaucoup plus difficile, car elle est jonchée de quelques changements insignifiants et anciens.

Est-ce que des situations de ce genre vous sont arrivées? Que suggérez-vous, en particulier pour faciliter le repérage des différences importantes lors de la fusion? Comme une résolution temporaire (espérons-le), je vais essayer et #ifdef sur les régions supprimées, de sorte que SVN penserait que le code est toujours là et qu'il est préférable de fusionner. (Malheureusement, cela va rendre le code un peu moche, et devenir plus laid quand plus de fonctions sont supprimées.)

Answer 1

Eh bien, je ne suis pas un expert SVN, mais je peux vous suggérer d'exporter un patch depuis un commit de votre première branche et d'appliquer le patch dans la deuxième branche. Je suppose que c'est presque ce que fait la commande Mercurial 'hg transplant XXX'. Je ne sais pas si une commande équivalente SVN existe, cependant.

Answer 2

Vous pouvez envisager

1. si vos commits sont assez fréquents, et
2. si vous fusionnez la révision correcte ou une plage de révisions.

Il me semble que vous n'obtenez pas tout à fait la granularité que vous voulez avec vos révisions; c'est-à-dire qu'une révision englobe de nombreux changements. Soit cela ou vous essayez de fusionner une plus large gamme de révisions que vous n'en avez besoin. Dans tous les cas, cela peut être utile si vous vous engagez plus souvent.

Dans ce cas particulier, vous devrez fusionner manuellement les fichiers — une fois que vous le faites, vous devriez être en mesure de fusionner les révisions suivantes qui n'impliquent pas foo() sans aucune intervention.

Answer 3

Si vous modifiez une fonction sur la jonction que vous avez supprimée sur la branche, vous pouvez vous attendre à un conflit, c'est naturel.

Et oui, pour le "côté droit", vous verrez tous les changements entre le tronc et la branche. Si vous y réfléchissez, c'est le seul ensemble de changements qu'il est logique de montrer. (Au moins, c'est le cas avec la version 1.4 sur le serveur, les versions ultérieures avec un meilleur suivi de la fusion peuvent éventuellement être plus concis, mais vous devez avoir une version client suffisante, je ne suis pas sûr. pour mettre à niveau ... soupir.) Mais les changements de branche montrés devraient tous être automatiquement marqués comme non modifiés par la fusion, à moins qu'ils ne soient en conflit ou autrement interagissent avec les changements du tronc.

Vous ne devriez jamais être surpris par l'ensemble des changements que vous voyez. Si vous l'êtes, vous avez soit sélectionné les mauvaises révisions, soit mal compris quelque chose sur le fonctionnement du processus de fusion.