Editer les conflits lors d'un merge SVN : 2-way compare ou 3-way compare
Par MD3804-GANDI le jeudi 29 octobre 2009, 10:14 - IDE - Lien permanent
Hier, j'ai du réaliser un merge SVN avec un collègue où nous avons du merger le trunk sur une branche . Pour cela nous avons installer la nouvelle version d'Eclipse Galileo et le plugin subversive. (les versions antérieures d'Eclipse et de subversive ne gérant que la version 1.4 de svn, la version 1.5 étant beaucoup mieux pour réaliser des merges).
Puis vint le moment douloureux de l'édition des conflits, c'est là que je regrette de ne pas utiliser d'outils comme launchpad, bazaar(systeme utilisé par Canonical, la boite qui a fait Ubuntu, pour gérer les différents projets open source qu'ils maintiennent) ou Git, mais cela fera l'objet d'un post à part. bref ! nous sommes sous SVN.
Nous cliquons donc sur éditer les conflits et nous nous posons la question sur une option de l'éditeur de conflit dans Eclipse : 'Show Ancestor Pane' et 2-way or 3-way qui permet de faire une comparaison tripartite ou pas. lorsque nous passons en comparaison '3-way' nous avons des conflits, et lorsque que nous passons en '2-way' nous n'en avons plus. Quelle est donc la bonne façon de faire ?
Nous cliquons donc sur éditer les conflits et nous nous posons la question sur une option de l'éditeur de conflit dans Eclipse : 'Show Ancestor Pane' et 2-way or 3-way qui permet de faire une comparaison tripartite ou pas. lorsque nous passons en comparaison '3-way' nous avons des conflits, et lorsque que nous passons en '2-way' nous n'en avons plus. Quelle est donc la bonne façon de faire ?
Comme dans la majorité des cas, cela dépend de ce que l'on veut faire. Plutôt que de rentrer dans des explication fumeuse, je préfère employé une analogie :
- en 2 way : on ne regarde que la version à intégrer (dans notre cas : le trunk) et la version qui reçoit les modifications (dans notre cas : la branche). l'analogie que l'on peut prendre est : je checkout, je fais des modifications, j'update, aucune modif n'a été faite sur la partie de code que j'ai modifiée, donc pas de conflit, puis je commit.
- en 3 way : on utilise les deux versions du '2-way' plus une version antérieure commune (ici, la version directement du trunk directement inférieure). le but est de faire un merge où l'on s'intéresse aux modifications apportées sur la version à intégrer. l'analogie est alors : je checkout, je fais des modifications, j'update , et la j'ai un conflit car la version que j'ai modifié à subit des modifications sur le référentiel et je dois décider ou non de prendre les dernières modifications ou de garder les miennes. Le conflit apparait lorsque je dois faire un choix entre ma version actuelle et deux autres versions.
Reste à choisir la stratégie de merge. Pour nous ça sera du '2-way'
Pour finir voici un lien en anglais : http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.user/concepts/concepts-29.htm
Hope it helps !