J'ai un patch de noyau pour une version de noyau légèrement différente puis celle que j'essaie de patcher. Inutile de dire que le patch échoue partiellement. Je peux certainement le réparer manuellement, mais je me demandais peut-être un utilitaire de patch graphique pouvant être utilisé pour résoudre les conflits.
3 Réponses :
Je ne connais pas d'un utilitaire de patch graphique, mais ce que je ferais probablement, c'est d'obtenir le (s) fichier (s) de l'ancienne version du noyau, appliquez le patch pour obtenir un ancien fichier ancien (s) corrigé (en conservant l'ancien fichier ( s)), Obtenez le (s) fichier (s) dans la nouvelle version du noyau, puis utilisez un outil de fusion à 3 voies tel que Gnu meld .
Cette procédure prend beaucoup de temps, mais je l'ai trouvé extrêmement utile pour résoudre les conflits de subversion (très similaire à ce que vous essayez d'accomplir). Et, il vous permet de déterminer rapidement comment différent du fichier dans les deux versions du noyau sont, ce qui a changé et divers changements dont vous aurez probablement besoin de faire aux lignes de correctifs afin de les rendre compatibles avec le (s) fichier (s).
Je sais sur Meld. Le problème évident avec ce que vous avez suggéré est qu'il y a trop de différence, en plus du patch, entre les anciennes versions du noyau et les nouvelles versions du noyau. Il semble que l'utilité que je recherche n'existe pas, alors je vais devoir le faire manuellement. Merci quand même.
Il existe de nombreux utilitaires de correction graphique, essayez Un autre outil utile est J'ai tendance à l'utiliser avec un système de révision sous-jacent, je suis donc heureux de revenir à ses changements s'il a tort, comme tel que j'utilise:
Qui dit de faire la transformation en place, il va parfois faire la bonne chose, d'autres fois où vous vous retrouvez avec >>> les marqueurs et peut éditer à la main, mais il est plus facile que d'utiliser un fichier REJ à la main. Si cela fait vraiment un mauvais travail, j'utilise mon système de contrôle de révision (GIT) pour revenir à l'original. meld , diffus , kdiiff3 ou dirdiff , ils devraient être emballé pour votre distribution.
wiggle , qui "tente plus difficile" de résoudre les conflits et transformera un fichier REJ du correctif en un conflit en ligne de style CVS avec >>> Marqueurs.
wiggle -v -replace
Ouais, j'ai rencontré une situation similaire en essayant d'appliquer des correctifs Firefox Light V27 à Firefox V28 Beta 4. L'équipe Mozilla a renommé certaines choses, donc ce n'est pas une goutte directe. J'espérais faire cela afin que je puisse le faire pour pouvoir compiler. Pour Linux. J'ai fini par ouvrir le patch dans un éditeur de texte et le code dans un autre.
C'était un mousepad, mais il pouvait être n'importe quel éditeur de texte simple pour cette affaire, Gedit, Leafpad, Geany ... Puis fait tous les mods à la main, côte à côte, d'une fenêtre à l'autre, mais c'est si lent de cette façon. "Trouver" a été utile pour sauter aux bons endroits d'édition.
Je devrais également mentionner que si vous collez le morceau du correctif que vous utilisez dans une fenêtre vide, vous pouvez trouver et remplacer le symbole +, puis le remplacer, puis le remplacer par rien, de sorte qu'il en baisse le code utilisable. .. qui est plus facile pour les grands blocs de code ajouté, au lieu de twiddling vos doigts sur les touches UP-SHROW et DELETE.